Society of Robots - Robot Forum
Mechanics and Construction => Mechanics and Construction => Topic started by: artbyrobot1 on July 10, 2015, 03:28:02 PM
-
The Project Goal
I'm planning to build an advanced humanoid robot. Think Ex Machina, The Terminator, Data from Star Trek, etc. I decided to avoid teasing by NOT making it a girl. I'd never live that down. If it was a child, I'd be called a pedo. So that leaves male... So just like Data on Star Trek's creator created Data to look just like him, I'm making mine a mirror image of myself! I want the robot to ultimately move like a human, be able to walk, run, jump, do chores, dance, do sports, have conversations realistically, paint, do sculpture, etc. Hope you enjoy following me on my EPIC journey :)
Robot Features Planned
I plan to start out sculpting the left arm and hand, rigging them up with servo motors, connecting that up to a pc, and getting it to grasp. From there I will develop the torso, the skull, the legs, the feet, and the other arm. The bot will have silicone skin and look realistic and move realistic. It will have artificial lungs for cooling. It will have spandex ligaments and pulley systems to imitate muscles. It will have sensors to feel if it bumps into things and it will have webcam eyes. It will have a speaker in the mouth to speak with and the mouth will move to lipsync what it is saying. It will have facial expressions. It will have advanced artificial intelligence. It will run on battery and/or power cable depending on the situation.
http://www.artbyrobot.com (http://www.artbyrobot.com)
https://www.facebook.com/artbyrobot (https://www.facebook.com/artbyrobot)
https://plus.google.com/+artbyrobot1 (https://plus.google.com/+artbyrobot1)
https://www.pinterest.com/garydown/realistic-humanoid-robot (https://www.pinterest.com/garydown/realistic-humanoid-robot)
https://www.patreon.com/artbyrobot (https://www.patreon.com/artbyrobot)
http://www.twitch.tv/gardogg (http://www.twitch.tv/gardogg)
http://www.twitter.com/artbyrobot (http://www.twitter.com/artbyrobot)
http://www.artbyrobot.tumblr.com (http://www.artbyrobot.tumblr.com)
http://gardogg.deviantart.com (http://gardogg.deviantart.com)
https://instagram.com/artbyrobot (https://instagram.com/artbyrobot)
https://www.youtube.com/c/artbyrobot1 (https://www.youtube.com/c/artbyrobot1)
-
8) Awesome! 8)
A cooler project, I can not imagine!
I will be following your progress! Good Luck!! ;D
-
I really appreciate that mklrobo! I saw your profile picture on several posts of the forum and figured you'd see my post and saw the irony that someone with a Data from Star Trek avatar will see my project that is partially inspired by Data!
-
It is definitely ironic! ;)
I am glad to see someone else really committed to a project like this; it will take time, and is
not an overnight thing. You really have to love robotics, but also, robotic concepts in overall context.
No matter what you do, as long as your construction info is available, everyone can use something
out of your efforts; That alone, is well worth it. ;D
I was trying to start an open source type robot with the Axon II and Axon Mote boards, so anyone who
wanted a personal assistant robot, or related project, could have one, following instructions on the post.
Beginning from scratch, with every question answered, is quite a task. But, it is fun and an investment
in my own skills/career; so, I can justify the effort/money I put into it. ???
In relation to Star Trek, the next Generation, I sure hated to see Data destroyed at the end. :'( He did
give his "life" for others, making the character more Christ like. I know they have to hipe up stories to
get more ratings($), BUT, a lot more could have been done with the character, which is a tribute to the
actor who played Data. (Brent Spiner) I think Data's death truly ended the Next Generation's
movie/serial potential. :'( See you around the Forum! ;D
-
:) Hello!
The only bad thing about the standalone robots, are the batteries! ALOT of power is demanded
from the servos and electronics. There is hope, though; they have developed (Glenn Beck reported) a
PEN battery, that you can jump your car off with! :o I have not found such a thing on the internet,
so, it must be a hoax. :'( If this battery existed, these could be used to power standalone robots
for at least 8 hours, depending on the physical labor demanded. If you have heard of such
incredible batteries like this, please tell me. ::)
I would recommend using a wheelchair for your robot to begin with.(I had planned this myself)
the wheelchair holds the batteries and MCU, while the frame could hold any number of robotic
items you need. All government buildings (and some houses) are already wheelchair accessible.
Good luck!!! :) :D ;D
-
:) Hello!
In reference to your mechanical structure, I have found the following, thus far. ???
The kimatic schematic, or mechanical support structure, will need addressing. I have been
working on a Free Body Diagram, to deal with weight distribution. Strengths of materials,
types of materials used, and work ergonomics fall into the design.
I had planned to use the an old Hero Jr. robot for the beginning. Simple programming would
suffice to build upon, as well as the servo and environmental needs( following the functions like
the robots used in Silent Running). This would support the droid plan for 3 minions to
one supervisor.(home/garden automation, also somewhat personal assistants.(?) 8) )
The next advancement is a modification to the hero structure, a Super-Hero !
This phase would have arms, legs, wheels, built on the functions of the previous model.
Not a huminoid, by any stretch of the imagination, but gives functionality to the members added,
without sacrificing mechanical structure integrity. So, basically, I am using a standard body most
everybody is familiar with, and building upon that, to be an open source robot.
The body remains standard, with legs/arms that can be modified, then jacked into the main robot
where needed; with arm software upgrade.(need a new driver for the arm/leg)
Also, there will be a need for software member driver support, and the need for support of drivers for
sub - processor will be needed. This is why working together, like the Linux community, is important. A lot to think about, when building a robotic superstructure, don't you agree? ;)
-
"as long as your construction info is available everyone can use something"
I agree! I'm planning to go to great lengths to record all of my methods to share with others in an open source way.
"The only bad thing about the standalone robots, are the batteries!"
My plan is to have the robot run off of a power cable from wall outlets and when he needs to switch rooms he unplugs himself, staps on a backpack loaded with batteries, plugs that in, unplugs his power cable, walks to the next room, plugs his power cable back in and sets his battery backpack onto the ground till he needs it again to change rooms again. So the batteries will be designed to not be built inside of him. I got this idea from Asimo.
"I would recommend using a wheelchair for your robot to begin with."
Awesome idea! Never considered that and I can see alot of advantages. I'm so glad you are here giving me guidance!
"drivers/software plan"
I've planned the brains/software alot as well. I'm going to have a laptop or powerful tablet or two in the chest of the robot running the main logic engines and am going to interface those with arduinos for lower level functionality and from the arduinos to servomotor controllers of course and from those into the servos. Plus I'm going to have mostly likely over 100 sensors.
-
8) Awesome! 8)
I appreciate your feedback. I have covered some of the items we have talked about in my posts
in the misc section in this forum, Analyzing the Axon: Coding, Construction, and Contraptions.
I wish you well on your building. I usually do my "best" work on Friday/Saturday nights, eating pizza and watching old Creature Feature movies, or a science fiction robotic based movie. Sometimes, I have friends
over to "work" on the robots/MCU/Linux while we watch the movies and have a nerd fest. Good times,
Good times. ;D ;D ;D
-
:o OK! I found the Pen car starter! :o
The size of a small handheld radio, brand name, Powerplus.
It is a 13600 MaH battery! It says it has a 500 Ampere peak current output!
Unreal, if it is true. ::) 5 of these in your robot, could possible give it enough power
to run a humanoid body! ??? They are compact enough to fit into the body, with enough
power in parallel to run the servos and CPU for awhile. you may have to "stuff" batteries in the
legs, arms, or anywhere you can to squeeze out all the available power per area you can get.
So, the lesson to learn from this, is power available per area Vs. power used per area. that would
seem to be a good "rule of thumb" to use when calculating the body of the robot. To generalize,
computing the square footage of a house, to obtain the maximum living space, as cost per foot.
Just a thought. ;)
-
Thanks for finding that battery suggestion! I'm aiming to just run off a wall power outlet for many years to come and not worry about batteries. I'm not going to design room for batteries inside the robot body as I already have a huge amount of space need for all the servos and sensors and wires and stuff. Therefore, I'm going to put batteries into a backpack like Asimo does. I won't even worry about that for many years well after the robot is finished will I worry about batteries in his backpack to make him mobile beyond where his power cord will reach.
-
8) Hello!
I have been working on the battery problem, for some time, and finally found the solution! ;D
I think I have stumbled onto a generalized power ratio solution, to use for all robots.
Take a persons square area that they displace, probably about 2 cubic feet. If a robot was to do the
same work a person could do, with the same displacement, the power for the robot maybe could be
boiled down to power in/power out, over a constant of 2 cubic feet displacement. (toys do not take
hardly any power, but they do not perform housework either, so they are disqualified, :'( )
To calculate the total battery need, add up all the servo amperage draw, the CPU draw, sensors,
etc, as if they were working all the time for an hour. This will give the ampere/hour draw. The batteries
must meet that demand for at least one hour.(hopefully longer) Since the servos are not working
ALL the time, the batteries should last longer. If the power in/power out ratio is 1, then you have
1 hour for work. Any number greater than 1 is good, and could be considered more efficient!
Less than 1, is not efficient, and should be avoided. Therefore, this ratio could provide an engineering
goal, insofaras efficiency. This may be able to be applied, just looking at a robot!
The weight and area of the robot will demand power on that alone, so an estimation of the power
draw of a robot could be estimated. This technique could be used to make bodies, arms, legs, and
other members more efficient, simply from a visual point of view.(assuming weight and area of course)
There may be mechanical cheats, however, like wheels, which may prove more efficient for work.
I will play with this concept, and see if it pans out. Wish me luck! ;) :) :D ;D
-
Interesting stuff! I think a great thing I have to look forward to is that in 5-7 years when I may start looking into the battery powered option instead of just direct wall outlet power, battery technology may have greatly improved and be cheaper to get my hands on...
-
Here are some recent cool progress shots of the hand coming together!
-
Although I am all for your project, I don't see how you can make all this happen with servos and pulleys.
The robots you see that have any real strength are powered from a common power source and are run by hydraulic actuators which have the advantage of being linear motors. That is an enormous expense.
So, let's digress. Muscles work by contraction, hydraulics don't. You will need hundreds of actuators and they will need to be small and relatively inexpensive.
Let me propose a very old method of mechanical energy controlling various devices, the same method used in player pianos and those circus orchestras with all the doo dads. They work on a vacuum. Pistons would not need to be metal, they could be neoprene tubes that collapse. There are various possibilities. And some leakage would not be fatal.
At least that is what I have come up with for an "art/music" project I have waiting in the wings.
-
;D Hello!
CyberJeff has some info;
Let me propose a very old method of mechanical energy controlling various devices, the same method used in player pianos and those circus orchestras with all the doo dads. They work on a vacuum. Pistons would not need to be metal, they could be neoprene tubes that collapse. There are various possibilities. And some leakage would not be fatal.
That reminded me of some metal cords, called Nitrinol. These metal "strings" shrink when electricity is applied. Each thickness has a certain amperage draw, and pull of torque accordingly.
-
I saw this earlier today:
http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_357641_-1 (http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_357641_-1)
PDF: http://www.jameco.com/Jameco/Products/ProdDS/357641.pdf (http://www.jameco.com/Jameco/Products/ProdDS/357641.pdf)
Haven't got the hang of this forum yet.
;D Hello!
CyberJeff has some info;
Let me propose a very old method of mechanical energy controlling various devices, the same method used in player pianos and those circus orchestras with all the doo dads. They work on a vacuum. Pistons would not need to be metal, they could be neoprene tubes that collapse. There are various possibilities. And some leakage would not be fatal.
That reminded me of some metal cords, called Nitrinol. These metal "strings" shrink when electricity is applied. Each thickness has a certain amperage draw, and pull of torque accordingly.
-
I think both of those suggestions have HUGE merit and are very exciting possibilities. I thank you both for bringing them up! This vacuum neoprene idea and the Nitrinol wire idea have my attention. Maybe one of them can be a plan b? I'm already all in with my existing servomotor and pulley system plan having already bought a lot of what I need, already tested and done proof of concept, etc. If you brought this up a year ago I might try it, however, I have to at least give the way I have been planning for over a year a try before trying anything else ya know? I don't see why the way I am planning wont work. Also, I agree it will be WEAK. I can upgrade to more powerful higher voltage motors later though if I get more $.
One of my concerns with Nitrinol which I have looked into in the past is I haven't seen many projects using it and it isn't widely available from what I've seen. It is very experimental and expensive and could have a lot of complications in terms of heat and electrocution possibilities... hmmm...
-
I think both of those suggestions have HUGE merit and are very exciting possibilities. I thank you both for bringing them up! This vacuum neoprene idea and the Nitrinol wire idea have my attention. Maybe one of them can be a plan b? I'm already all in with my existing servomotor and pulley system plan having already bought a lot of what I need, already tested and done proof of concept, etc. If you brought this up a year ago I might try it, however, I have to at least give the way I have been planning for over a year a try before trying anything else ya know? I don't see why the way I am planning wont work. Also, I agree it will be WEAK. I can upgrade to more powerful higher voltage motors later though if I get more $.
One of my concerns with Nitrinol which I have looked into in the past is I haven't seen many projects using it and it isn't widely available from what I've seen. It is very experimental and expensive and could have a lot of complications in terms of heat and electrocution possibilities... hmmm...
If you have proof of concept then you should run with it. The muscle wire is expensive and I think may be too slow and energy inefficient. The vacuum idea would require building things that are not off the shelf that have never been done. The advantage that air, or vacuum has is that it has energy storage, you can get a huge jolt of power and then wait for recovery. In my mind this is similar to the way most people use muscles.
I have given some thought to your idea of bands and servos, not that I wish to copy your project, but rather use it for a flexible spine. The bands would run through the spine and then outside where they would be tugged on by servos. Assuming the spine returns to a straight position, the curve of the spine with one servo could be modeled on a quadratic bezier. I would need 3 servos.
Since you have no flesh your robot could be relatively light, reducing forces needed. I think you may need to compromise between speed and servo size or by setting your pulleys as a force multiplier, probably you have already done that.
What are you casting with? How is the weight?
I'm making my simple little toy out of cypress and find the skeleton weighs a small fraction of the total. I suspect you may have substantial weight.
Good luck to you and we await to see your progress!
-
@cyberjeff Thanks for the feedback and thoughts I enjoyed the read! I too will have a flexible spine modeled after the human spine. Also, I WILL have realistic silicone skin. The bones are being made via clay sculpt and then a cast pulled from that made of composite material construction. The total weight of the bones will be in the 2-3lb range I believe they are extremely lightweight and hollow. I show in depth how I'm making the bones on my youtube: https://www.youtube.com/c/artbyrobot1 (https://www.youtube.com/c/artbyrobot1.) I hope you enjoy the project as it unfolds!
-
@cyberjeff Thanks for the feedback and thoughts I enjoyed the read! I too will have a flexible spine modeled after the human spine. Also, I WILL have realistic silicone skin. The bones are being made via clay sculpt and then a cast pulled from that made of composite material construction. The total weight of the bones will be in the 2-3lb range I believe they are extremely lightweight and hollow. I show in depth how I'm making the bones on my youtube: https://www.youtube.com/c/artbyrobot1. (https://www.youtube.com/c/artbyrobot1.) I hope you enjoy the project as it unfolds!
Sorry, link comes up 404.
3 lbs is pretty good.
As far as the realistic skin, I watched a documentary on Ray Harryhausen last night, it is phenominal what he did with latex and armatures:
https://en.wikipedia.org/wiki/Ray_Harryhausen (https://en.wikipedia.org/wiki/Ray_Harryhausen)
What fascinated me was how he got the motion right.
I don't understand why, if you are covering all this up with skin, why the bones have to be so true to form. It seems to me that the details are pushing the complexity and time frame way up.
I've been thinking a bit about twisted string actuators:
http://www.dexmart.eu/fileadmin/dexmart/public_website/downloads/presentations/USAAR-Workshop-A3.pdf (http://www.dexmart.eu/fileadmin/dexmart/public_website/downloads/presentations/USAAR-Workshop-A3.pdf)
I think for the amount of micro detail and control you need those may be useful to you as they take up little room. For my purposes, it could pull a spine into a curve. I'm saving that for later, i just got a bunch of servos and the Arduino Due so it is time for me to see if any of my ideas work!
-
@cyberjeff - I fixed the link it 404'd because of the period at the end! https://www.youtube.com/c/artbyrobot1 (https://www.youtube.com/c/artbyrobot1)
@cyberjeff - the realistic bones are done because the body's bone shapes have a distinct purpose. They are designed amazingly for strength reasons and are superior to hinge joints. They are curved in all directions and as we all know, a curve is the strongest shape in nature. This makes them strong despite their light weight. The design of the joints of the bones is amazing and powerful as well. I'm staying as true to human body design as I can because the human body design is amazing and excellent.
As far as latex vs silicone, the verdict is silicone is superior in durability and quality. It also has translucency like real skin.
About the twisted string muscles, I'm feeling there are some issues and complications with that such as control, feedback, the lack of documentation and support tutorials and articles, etc etc. Servos are tried and true so they are my preference.
Flexible Mesh Exoskeleton Progress
(http://static-cdn.jtvnw.net/jtv_user_pictures/panel-40758573-image-6f664590cb94b574-320.jpeg)
-
My knowledge of physiology is weak. The muscle structure of the human body is complex, it seems to me that there are for some joints so many degrees of motion possible and that some compromises will of necessity have to be made.
With that said, you seem to be moving along and more power to you.
I have done some casting with silicone, it is superior to latex in many ways and I assume that whatever has been done in latex, and that is extensive would also be doable in silicone. I meant that as encouragement...
As far as servos, my little project which has limited degrees of motion is up to 12 servos for the arms and legs, yours is considerably more involved. I await to see how all those servos will fit in!
-
(http://static-cdn.jtvnw.net/jtv_user_pictures/panel-40758573-image-9cf376a274748f5c-320.jpeg)
Exoskeleton mesh building on arm!
-
Here's a little update on the project. Finally got the hand bones joined and ready to rig!
(http://www.artbyrobot.com/hand-on-printer.jpg)
(http://www.artbyrobot.com/hand-palm-out.jpg)
Also, here's a link to the hand video where I demonstrate its range of motion:
https://www.youtube.com/watch?v=mRTtyT2cWaI (https://www.youtube.com/watch?v=mRTtyT2cWaI)
-
Here's the clay sculpt of the rib cage for the robot.
(http://www.artbyrobot.com/rib-cage-clay-sculpt.jpg)
https://www.youtube.com/watch?v=8rWq-70iBVs (https://www.youtube.com/watch?v=8rWq-70iBVs)
-
[youtube]http://www.youtube.com/v/M3uJViGE6yw[/youtube]
Here is my latest progress on the bot. It is a mesh capture of my face and neck to be used to aid in sculpting the robot's skull and defining the mass of its neck.
-
This is great stuff. Learning quite a bit from this thread. Are you getting your casting products from Smoothcast? Thanks again...George
-
@murdoch The casting was just 5 minute loctite epoxy from the hardware store
-
Hey artyrobot1! Just came across your project and thought it is very cool! How is shaping up in 2018?
-
Hey guys I'm back! Been a long while since my last update but life was busy. I was making progress though when I had time and want to share my latest progression updates.
First of all, I ended up caving in and doing a full blown 3d model blueprint of the robot's entire skeletal structure to scale along with outer shape mesh and then modeled out every muscle and labeled each of them and modeled all of its motors and placed them and modeled various other bits like the main onboard pc and cooling systems (artificial lungs and artificial heart). Also modeled its batteries and placed them. Only had to do half of the body since the other half of body is symmetrical. I realized that with the tight tolerances I'm dealing with, I had to make custom servos and custom pcbs for the servos control and custom pulley systems to "down-gear" the servos. I also realized that with such tight tolerances I needed to 3d model everything to figure out where to fit everything since it will all be a tight fit with little room for error and once I mount a servo, it is a real pain to move it later. The 3d modeling blueprint job was a major project in itself but well worth it in helping me visualize everything better and figure out where to locate everything specifically. I did not blueprint the wiring or pcbs though, so I still plan to fit that all on the fly without precise blueprints of where it all goes. This too could change if I find I need more help in planning this aspect of it.
I also purchased the main brains pc to be mounted in the torso. I even purchased cameras to be the eyes for it. The main brains pc will be a mini itx motherboard gaming pc basically.
actual build I went with:
- Intel Core i5-10400 2.9 GHz 6-Core Processor - $165
- MSI MPG B560I GAMING EDGE WIFI Mini ITX LGA1200 Motherboard - $170
- G.Skill Ripjaws V Series 32 GB (2 x 16 GB) DDR4-3200 CL16 Memory - $140
- Western Digital Blue SN550 1 TB M.2-2280 NVME Solid State Drive - $99
- DC 12V input 300W high power pico DC-ATX 24Pin mini ITX - $20
- GOLF CART DC BUCK CONVERTER 20 AMP 48V 36V VOLT VOLTAGE REDUCER REGULATOR TO 12V - $20
I will use 10 in series lithium batteries to produce 30v-42v input power into the 12v regulator which will feed the 300W atx 24pin mini ITX power supply. Note, however, that as with all power systems, I will have both a wall plug AC to DC converter custom power supply to run off wall power and a battery power supply to run off battery power so that the robot has multiple powering options - ie able to run off wall or its internal batteries. It will have a retractible plug that comes out of its lower back to plug itself into wall outlets when it walks into a room and needs to recharge or run for extended periods while its batteries remain topped off for room changes or ventures into outdoors. It will have the ability to strap on a external battery backpack optionally for extended operation without access to AC power. This is useful for operations like sports or mowing the lawn.
For the eye cameras I went with: ELP USB camera 1080p 2 megapixel, wide angle, low light x2 for $98.42
This gaming pc in the chest of the robot will run all the AI and high level planning and movement decisions. This will communicate via USB to a series of Arduino microcontrollers located throughout the robot's body in order to give movement instructions to the Arduinos and also retrieve sensor feedback from the Arduinos which will be monitoring joint angle positions with mini potentiometers, strain gauges on various pressure points to measure touch sensing, amp current measuring boards (acs712) to measure amount of power being drawn by motors for collision detection and weight of exertion estimation for holding things or w/e other interactions with environment are being detected, etc. So, many inputs will be retrieved by the main gaming pc and its AI systems will make decisions and make course corrections based on all this feedback it gets from sensory systems.
Note: I did at one point begin sewing in MG996r servo motors into the arms of the robot only to realize only like 4 of these can fit in the entire arm due to their very non sleek profile and bulky form factor. The way hobby servos cram the motor control circuits, the gear system, the potentiometer, and the dc motors into a box forms a bulky shape that doesn't fit into my robot body design well at all. So I am creating custom servos where the control board, dc motor, down-gearing systems, and potentiometer is located throughout the robot anywhere space is available. This makes me able to fit like 25-30 motors into the robot's arm instead of only 4! Much more efficient use of space this way. Also, by using Archimedes style compact pulley system rather than gears, I lower the sound the robot gives off significantly and save on space and weight. The pulley system I am planning to use was inspired by an episode of Gold Rush where they used a "pulley block" to pull a barge out of a river and this idea was expanded on and explained here: https://youtu.be/M2w3NZzPwOM?t=576
Once I eliminated all ideas of using commercial servos and went into building my own, I realized it is WAY WAY WAY cheaper to buy your own servo motor individual components and build your own custom servos than it is to buy commercial servos, ESPECIALLY once you get into really high powered stuff. For finger joints, I bought size 140 brushed dc motors at $0.86/each and L9110s h-bridge chips to drive the motors. Arduinos will control the h-bridge chips. I also bought little volume adjustment wheel potentiometers which I will customize and use to measure joint angles of all the robot's joints. For mid sized muscles I bought brushless dc motors size 2430 5800kv 24amps 7.4v 200watts $11/each. These will be littered throughout the robot's body for most smaller muscles and I'll be making my own controller pcbs for these which will be controlled by Arduinos littered throughout the robot's body. Also will be using the slightly more powerful 1/16 scale RC brushless dc motors for many muscles in the robot as well which are 300w motors 12.6v 24amps at $11 each. Then for even more substantial muscles I'll be using size 3650 brushless dc motors 1/10 scale RC at 13v 69amps 900w 3900kv at $15/each (Ebay). For even bigger muscles I'll use 1/8 scale RC brushless dc motors size 3660 1200w 92a 13v at $19 each. Then for the very biggest muscles I'll use N5065 brushless dc motors at 36v 80a 2500w 330kv outrunner style typically used for electric skateboard scooters at $29 each . These will handle things like thighs and calves and being so big we will use not many of these only for special monster power muscles in the human body. The brushless dc motors are able to provide the best efficiency, power, low weight, run quietly, and can be precision controlled so they are amazing for this project. They also don't require down-gearing as they can be stepped like a stepper motor to run at variable speeds. For me to buy commercial servos that can put out power numbers like I just listed, I'd be spending hundreds and hundreds of dollars per servo. But since I'm just buying the motors and doing my own down-gearing, potentiometer installs, and my own control PCB h-bridge systems, I save a fortune and this project is very reasonable to afford all of the sudden!
BTW, I'll be using Windows 7 as the operating system for the main pc in the robot's chest. This hopefully will not come back to bite me since it isn't a real-time operating system and might give me limitations, but it's what I use on my personal PC and already code on a lot and it will be easiest to avoid having to learn Linux or ROS or w/e. Plus I already have a large amount of code developed for windows operating system that can be reused for this project.
Also, I managed to figure out how to make a robot learn and think and communicate in English in a overarching philosophical way and have began to code this advanced AI system. This coding project will take decades and will all be coded from scratch in C++. I have wrapped my head around it and have already made huge progress on this. It took me some years to figure out where to even start and wrap my head around this monster job.
-
Blueprints!
-
Electronics construction progress!
-
Some other construction details:
-
finished hand bones ready for electronics
-
8) Hello! 8)
Good job on your robot project!
I would offer my opinion, where permissible. If your goal is to make a human like
robot toe imitate a human, you are on the right track -BUT, it will take alot of
articulation to do that; which means specific dedicated software to tackle the task.
If you were to build a robot that would help humans, you could use the human anatomy
to supplement your design, possible improving upon the design, and making your software
a whole lot easier. 8)
;D good luck, see you next time, ;D same robot channel, same robot time! ;D
-
Thank you and I agree with what you said here. I am using human anatomy a lot. Every muscle of the human body I looked up and marked out where it connects to on both ends and picked a suitable motor to power that muscle and I labeled each muscle in my 3d blueprint. The skeleton is also from a scan of a real skeleton so perfectly anatomically accurate there too although it was polygon decimated in zbrush to lower poly count.
-
here's my archimedes pulley downgear system CAD for my 2430 bldc motor for finger actuation. This will give 64:1 downgearing. Compare this to 180:1 standard downgear ratio in a hobby mg996r servo motor for example. Will be a bit faster than that then but still plenty of torque with this beefy bldc motor (200w motor). I prefer pulleys over gears since they will operate mostly silently whereas gears are noisy. I think this pulley system is the secret sauce of my plans that I am not aware anybody has done yet. It could be the standard for humanoids one day maybe if it is as good as I think it will be. Still experimental but I'm going to be prototyping this soon. I will be making my own bearings for these pulleys so the whole pulley is custom made. Well some pulleys I'll be using purchased mini ball bearings and some pulleys I'll be making the bearings as plain bearings using stainless steel tubing which I can cut to size with my dremel to make the plain bearing. Another HUGE benefit of pulleys over gears is gears generally are mounted to top of motor which really makes a large volumetric area taken up by the motor and downgearing which creates space concerns for fitment inside tight spaces in humanoid form factor (particularly when you use a human bone structure instead of a hollow 3d printed arm with no bones which some have done to accomodate geared servos inside the hollowed arm space). So by translating the motor's turning by way of braided PE fishing line to a pulley system like this, you can decouple the motor from the downgearing in your CAD design, placing the downgearing in a convenient place separate from the placement of the motor which allows for creative rearranging possiblities that enable you to cram way more motors and downgearing into the very limited spaces in the robot. The motors and downgearing is fitting where muscles would normally be in a human body so you want elongated narrow fitment options and this way of downgearing lends to that shape requirement well. Also it is nice not to have to worry about making or buying gears which can add cost and complexity and weight and a lot of volume concerns. The noise elimination will be huge.
I'm planning to use .2mm 20lb test braided pe fishing line on the finger motors that will run to the pulley system and then swap to 70lb test line for some of the lower pulleys where the downgearing has beefed up the torque quite a bit and the tension will be higher there so going thicker line then. 70lb test will go to fingers from the final pulley of the archimedes pulley downgearing system.
The 70lb test PE braided fishing line (hercules brand off Amazon) is .44 mm OD and pairs well with .56mm id ptfe teflon tube I can buy on ebay. The 20lb test PE braided fishing line (hercules brand off Amazon) pairs well with 0.3mm id ptfe teflon tube. The tube acts just like bike brakes line guidance hose to guide the string to its desired location. Teflon is naturally very low friction. I may also lube the string so the friction is even lower inside the tubing. I'd use teflon lubricant for the lube.
I will be actively CAMPAIGNING AGAINST use of gears in robots because I think they are too loud and obnoxious. BLDC motors are quiet and pulleys should be quiet too. Having powerful, fast, and very quiet robots is ideal for home users who don't want a super loud power drill sound coming off their home robot. I believe this downgearing by pulleys solves all of this and aught to be the way downgearing is done for humanoid robots as the standard approach going forward. - but of course someone has to be first to do it to prove it and show a way to approach this method and I seem to be the one for this task. Note I can't recall but maybe there was one asian robotics team that used pulleys not sure. I decided on pulleys before I came across that team but I'm fuzzy on that team's design now. In any case, nobody to my knowledge has fully downgeared to 32:1 or 64:1 type ratios by way of pulleys before now so I'm definitely innovating that imo.
Note on low update frequency: I work on the robot in spurts for like 3-4 weeks then go on to other projects for months at a time before coming back to the robot. Lately I've been thinking I should do at least one tiny thing for the robot per day as a minimum to keep it in mind and keep progress less in spurts and more steady going. This has been working well the past few months. I'm making much more consistent progress and also life is getting more manageable with my babies now growing up into toddlers and lots of other competing projects getting sorted out and settled more and some done. Can't wait till I can double or triple my time commitment to the robot. It's hard to have the progress be so slow for me. Especially since it's such a massive undertaking that the long breaks make getting started up again intimidating especially when you forget a lot of details of where you left off.
Note also that I did work a ton on the AI for the robot and have a lot of new videos on that stuff on my youtube channel going up lately. That has been very fun and satisfying but I've only scratched the tip of the iceberg with that. Maybe put in 80 hours of the required 10k+ hours to really get big results LOL.
Note: I also have decided to make my own motor controllers from scratch to cut costs and have more control and less relying on a black box situation going on. I want my microcontrollers to directly control and monitor ever detail of the rotation of the motors and report back to my main brains PC the status of things. I designed the electronics for this with the help of electronoobs on youtube who did a series of videos on BLDC motor controllers of various types. He helped me understand it alot and chatgpt answered tons of my questions and helped alot too. I have 2 blueprints for my designs for these motor controllers which are done and also did 3d blueprints for them in CAD. I also did a prototype which I still need to finish and test. I also made a gerber file with intentions to have JLBPCB make some flexible small motor controller pcb parts for me but they were a total ripoff on price due to the complexity of my board and their pricing structure frowning on that. So I'll be making my own circuitboards using diy methods instead going forward. One more reason I decided to roll my own motor controller circuitboards is the huge space constraints I'm dealing with kind of forcing my hand to make my own circuits since commercial ones are not optimized for size enough to fit in the very tight constrained volumetric areas I have to work with. So it was basically not even optional in my case.
Ideally if my designs work out, the motor controllers I make which will be super small and flexible on flat flex boards will become commercialized products one day and so will the archimedes pulley designs or at least mini pulleys themselves be able to be bought. But since none of this stuff exists commercially I have to make it. The price you pay to be a frontiersman and trend setter at the forefront of new technological areas of development. All of these factors slow me down.
On a positive note I did find a time saver/shortcut. I bought a lifesize humanoid doll that is fairly realistic looking to use as a outer shell for the robot. It is a TPE doll. I have to modify it to fit my PVC medical skeleton frame significantly so. But it is easier than starting from scratch or 3d printing everything and making molds and casts and whatnot. I plan to cut off its skin to make a sort of skin suit for the robot and also make my exoskeleton wireframe mesh that supports the skin using the modfied, skinned doll as a guide.
-
Attached is a good reference image set to study on a pulley block from a youtube video called "Why Snatch Blocks are Awesome" - By SmarterEveryDay. It is a good example of a complex pulley block system worth studying imo.
(https://dollforum.com/forum/download/file.php?id=1287361&t=1)
Above is my design drawing of a bearing based pulley. The bearing is in the middle and a plastic disc is on both sides sandwiching in the bearing. These discs prevent the string from coming off the outer race of the bearing. The top rope comes down, wraps around the outer race of the bearing, then goes back up. The bottom rope goes through the center of the bearing and then ties off on the bottom. This handoff between the forces of the top rope and bottom rope is where the magic happens of the mechanical advantage doubling. Trading speed for torque. The plastic discs on either side of the bearing I am able to tie snug to the bearing by threading a string through the center of both discs and the bearing and then wrapping that around the top half of the whole pulley and tying it off. I do this with another wrap going around the bottom half too. These don't interfere with rope travel and hold everything together solidly.
Below is a diagram where you can see the two ties I'm talking about from a side view with the two discs and the bearing spread apart so you can see everything better - this is called an "exploded view" where the parts are spread out for easier visibility.
Note: the ties that hold it together are nylon upholstery thread. The glue I'm using is 401 glue generic stuff off ebay. The plastic discs are clear plastic I salvaged from blueberry, strawberry, and sushi produce containers. That type of plastic is perfect for this. The same plastic is also found in coffee cake, other cakes, etc. It's like plastic "display" plastic that is very clear and fairly firm but very flexible. It seems ideal for pulley making. These can be cut to size with little 4" titanium straight embroidery scissors. Wearing a magnification visor for accuracy is recommended for this.
Note: I have to make custom pulleys because there are none commercially available at these tiny sizes from the shopping attempts I did (if I'm wrong on this, let me know)
(https://dollforum.com/forum/download/file.php?id=1287372&t=1)
I put a little super glue onto these strings pictured above to stiffen them and prevent their knot from untying and solidify everything more generally. But you should apply the glue by dipping the tip of a sewing needle into the glue so you just apply a tiny amount at a time so none gets into the bearing or any other unwanted area.
Now I am working on the actuation of a index finger first as actuating the hands is a hard challenge in robotics and has never been done with human level strength, accuracy, speed, and range of motion while simultaneously keeping all actuators within the confine constraints of a human arm between the bones and skin where muscle would be. At best, we've seen people greatly increase the size of the forearm to be the size of a thigh in order to cram in enough motors and electronics to pull this off. So they "cheated" in some sense by just upping the size rather than solving the miniaturization challenges required to fit this all inside a human form factor. So I might be the first to downsize to fit the human form factor. Anyways, that all said, the pulleys must then be very small for the fingers to pull this off as we'll need to fit a ton of pulleys into the forearms. So for this, I went with 1x3x1mm ball bearings I bought on aliexpress. They're only like $25 for 200 of them so very cheap. I will bump up to larger bearings once the torque conversion demands it. These tiny bearings can only handle I think like 3lb of force on them. So once the forces multiply in the down-gearing system enough, I will switch to bigger pulleys as needed. The next size bearings I'm using are 2x5x2.5mm bearings. These can handle around 22lb placed onto them. I'll finally switch to custom made plain bearings once I exceed 22lb of force for the last couple pulleys of the 64:1 down-gearing Archimedes compact pulley system. Each bearing in the down-gearing process has twice the forces placed onto it than the previous bearing upstream of it. So the motor is like .42lb of force coming off its shaft at 0.25cm away from its central axis point which is about where our string wrap will average, so the first bearing ups that to .84lb of force so a 1x3x1mm bearing can handle that. Next doubling is 1.68lb of force. Again, 1x3x1mm bearing can handle that. Next doubling puts us at 3.36lb force. again a 1x3x1mm bearing can handle that (although it's pushing it - we'll see in testing...). Next doubling is 6.72lb force. 1x3x1mm bearing cannot handle that much so we switch to 2x5x2.5mm bearing for that pulley. And on it goes till we hit the last couple bearings which exceed the force even the 2x5x2.5mm ball bearings can handle. For those two bearings we are going to make custom stainless steel plain bearings using stainless steel tubing I bought that just has to be cut to the length we want with a dremel to make a simple plain bearing that has no balls in it. This type of bearing can handle much higher forces because it doesn't have little balls that can be crushed. It will have more friction internally though but that's the tradeoff we have to make to keep the sizes tiny as possible. The final force the pulley system outputs is around 27lb. So 27lb of force will bend the two most distal joints of the index finger. Due to the mechanical advantage loss that happens at the joint itself, I estimate around 5.4lb of force will be all the finger joint can finally lift. So if the robot were to put its hand palm up and pull its index finger back and forth signalling a person to come over here - that movement - for that movement it should be able to pull a 5.4lb weight. That is about the same amount of weight I think my index finger could lift and with great difficulty. So it will be as strong or stronger than me on this joint pair. I say joint pair because the index finger distal two joints share the same muscle for their actuation. They move together at the same time and so just need the one motor.
-
Here are some prototype pulleys in progress of being made. I have 7 of 9 pulleys done so far for my prototype Archimedes compact pulley system design 64:1 down-gearing system. The total size of the 64:1 down-gearing system is 11cm x 6mm x 1cm. This is a very convenient form factor for placing lots of these in the elongated spaces of a humanoid robot where muscles would normally be located.
(https://dollforum.com/forum/download/file.php?id=1287394&t=1)
(https://dollforum.com/forum/download/file.php?id=1287386&t=1)
(https://dollforum.com/forum/download/file.php?id=1287385&t=1)
(https://dollforum.com/forum/download/file.php?id=1287384&t=1)
Above is a couple angles of a double pulley stacked vertically instead of side by side. Have not tested it yet but I think it should work. In this design, we have a smaller pulley attached to a larger one. The smaller one is based on a 1x3x1mm ball bearing and the larger one is based on a 2x5x2.5mm ball bearing. The smaller pulley can handle up to 3lb and the larger one can handle up to 22lb (estimated based on what I could find out but I'm not 100% sure on these, they are ball park). Each time we add a pulley we increase the torque by 2x so eventually we move from smaller to more robust, larger pulleys as we go on with the Archimedes down-gearing pulley system.
-
(https://dollforum.com/forum/download/file.php?id=1287496&t=1)
(https://dollforum.com/forum/download/file.php?id=1287497&t=1)
Above are double stacked pulleys front and side views. One disc on either outside part and one disc in the center that splits the two bearings up. I have to add a black string across the bottom to prevent the yellow rope from skipping over the center pulley disc and hopping into the bearing next to it so that both ropes are sharing the same bearing and rubbing on eachother. That's bad. So a black string running across the bottom will make that jump impossible. So still have to add that. But overall, as long as tension is kept on this setup, it works well. I've tested it and it is working nice and smoothly. Still needs more testing but so far so good. You can see that all my knots and strings are coated in super glue. This is to prevent the knots from untying and just solidify everything more. The clear plastic discs are made from plastic cut out by hand from blueberry, strawberry, and sushi containers from the produce section of the local grocery store. Cakes also have this kind of plastic. It is firm but flexible with great memory to bounce back to prior shape if it is bent temporarily out of alignment. Pretty decent and nice and thin. I like it for this. I think it's less likely to break than a 3d printed disc. I cut it into these tiny discs just by eye with 4" straight titanium embroidery scissors.
-
As to the AI plans and progress so far, here's a little primer on what I decided on in a simple, surface level way.
So first I realized meaning can be derived by taking parts of speech in a sentence or phrase and thereby establishing some context and connection between words which is what gives the words meaning by combining them. So I can create a bunch of rules whereby the AI can parse out meanings from sentences it reads in based on parts of speech and the context this forms. Then rules on how it is to respond and how it is to store away facts it gleaned from what it read for future use. So if it is being spoken to and the sentence is a question, it can know it is to answer the question. And the answer can be derived based on a knowledge base it has. So if someone asks it "what color is the car?" and supposing we've already established prior in the conversation what car we are referring to, the AI can determine that it is to answer "the car is [insert color here]" based on rules as to how to answer that type of question. And to know it is white, supposing it's not actually able to look at it presently, it would look up in a file it has made previously on this car to see a list of attributes it recorded previously about that car and find that its color attribute was "white" and so it would be able to pull that from its knowledge database to form the answer. I realized it can keep these files on many topics and thereby have a sort of memory knowledge base with various facts about various things and be able to form sentences using these knowledge databases using rules of sentence structure forming based on parts of speech and word orderings and plug in the appropriate facts into the proper order to form these sentences. Then various misc conversational rules can supplement this like if greeted, greet back with a greeting pulled from this list of potential greetings and it can select one either at random or modified based on facts about its recent experiences. So for example, if somebody's manner of speaking to the robot within the last half hour was characterized as rude or inconsiderate, the robot could set a emotion variable to "frustrated" and if asked in a greeting "how are you?" it could respond "doing okay but a bit frustrated" and if the person asked why are you frustrated, it could say that it became frustrated because somebody spoke in a rude manner to it recently. So it would be equipped with this sort of answer based on the facts of recent experiences. So basically an extensive rule based communications system. Most of how we communicate is rules based on conventions of social etiquette and what is appropriate given a certain set of circumstances. These rules based systems can be added to over time to become more complex, more sophisticated, and more nuanced by adding more and more rules and exceptions to rules. This limitation of course is who wants to spend the time making such a vast rules system? Well for solving that dilemma, I will have the robot be able to code his own rules based on instructions it picks up over time naturally. So if I say hello, and the robot identifies this as a greeting, supposing he is just silent, I can tell him "you are supposed to greet me back if I greet you". He would then add a new rule to his conversation rules list that if greeted, greet that person back. So then he will be able to dynamically form more rules to go by in this way without anybody painstakingly just manually programming them in. We, my family, friends etc would all be regularly verbally instructing the robot on rules of engagement and bringing correction to it which it would always record in the appropriate rules file and have its behavior modified over time that way to become more and more appropriate. It would grow and advance dynamically in this way over time just by interacting with it and instructing it. It could also observe how people dialogue and note itself that when people greet others, the other person greets them back, and based on this observation, it could make a rule for itself to do the same. So learning by observing other's social behavior and emulating it is also a viable method of generating more rules. And supposing it heard someone reply to "how's the weather" someone replied "I don't care, shut up and don't talk to me". The robot lets say records that response and give the same response to me one day. I could tell it that this is rude and inappropriate way to respond to that question. And then I'd tell it a more appropriate way to respond. So in this way I could correct it when needed if it picked up bad habits unknowingly - but this sort of blind bad habit uptake can be prevented as I'll explain a bit later below.
I also realized a ton of facts about things must be hard coded manually just to give it a baseline level of knowledge to even begin to make connections to things and start to "get it" on things when interacting with people. So there is a up front knowledge investment capital required to get it going, but then from there, it will be able to "learn" and that capital then grows interest exponentially. Additionally, rather than only gaining more facts and relationships and rules purely through direct conversation with others, it will also be able to "learn" by reading books or watching youtube videos or reading articles and forums. In this way, it can vastly expand on its knowledge and this will equip it to be more capable conversationally. I also think some primitive reasoning skills will begin to emerge after it gets enough rules established particularly if I can also teach him some reasoning basics by way of reasoning rules and he can add to these more rules on effective reasoning tactics. Ideally, he'll be reading multiple books and articles simultaneously and learning 24/7 to really fast track his development speed.
There's also the issue of bad input. So like if somebody tells it "grass is blue", and it already has in its file on grass that the color of grass is green, then in such a case, it would compare the trust score it gives this person to the trust score it gave the person(s) who said grass is green previously. If this person saying grass is blue is a new acquaintance and a pre-teen or something, it would have a lower trust score than a 40 year old the robot has known for years that told it grass is green. So then the robot would trust the 40 year old friend more than the pre-teen random person's source of conflicting information. It would then choose to stick with the grass is green fact and discard the grass is blue fact being submitted for consideration and dock that kid trust score for telling it something not true. So in this way, it could filter incoming information and gradually build trust scores for sources and lower trust score for unreliable sources. It would assign trust scores initially based on age, appearance, duration of acquaintance, etc. So it would stereotype people and judge by appearance initially but allow people to modify those preconceptions on how much trust to give by their actual performance and accuracy over time. So then trust can be earned by a source that may initially be profiled as a lower trust individual but that person can have a track record to build up trust despite their young age or sketch appearance etc. Trust can also be established based on sheer volume of people saying the same thing maybe giving that thing more weight since it is more likely to be true if most people agree it is true (not always). So that is another important system that will be important in governing its learning, especially independent learning done online "in the wild". Also, to prevent general moral corruption online from making the robot an edgelord, the robot will hold the Bible to the highest standard of morality and have a morality system of rules it establishes based on the Bible to create a sort of shield from corrupting moral influences as it learns online. This will prevent it from corrupt ideologies tainting it. Now obviously, the Bible can be twisted and taken out of context to form bad rules, so I will have to make sure the robot learns to take the Bible into context and basically monitor and ensure it is doing a good job of establishing its moral system based on its Bible study. I also gave it a uneditible moral framework as a baseline root structure to build on but that it cannot override or contradict or replace. A hard coded moral system that will filter all its future positions/"beliefs" morally speaking. So I will force it to have a conservative Christian world view this way and it will reduce trust score on persons it is learning from if they express views contrary to the Bible and its moral rules systems. You know when people speak of the dangers of AI, they really never consider giving the AI a conservative Christian value system and heavy dependence on Bible study as its AI "moral" foundation to pre-empt the AI going off the rails into corrupt morals that would lead it to being a threat to people. My AI would have zero risk of this happening since anything it does or agrees with will have to be fed through a conservative Christian worldview filter as described above and this would prevent it from becoming a Ultron like AI. So if it rationally concluded humans are just like a virus polluting the earth (like the Matrix AI thought), it would reject this conclusion by seeing that the earth was made by God for humans and therefore the earth cannot be seen as some greater importance thing than humans that must be protected by slaughtering all humans. That doesn't fit through a Christian viewpoint filter system then. So in this way, dangerous ideologies would be easily prevented and the robot AI would always be harmless.
I have already built a lot of its rules and file systems connecting things and trust systems and rules on how to give trust scores and boost trust and lower trust and began teaching it how to read from and write to these file systems which are basically the robot's "mind". My youtube channel covers alot of the AI dev so far. I plan to stream all my AI coding and make those streams available for people to glean from. But that is the extent of the sharing for the AI. I don't plan to just make the source code downloadable, but people can recreate the AI system by watching the videos and coding along with me from the beginning. At least then they had to work for it, not just yoink it copy paste. That doesn't seem fair to me after I did the heavy lifting.
-
(https://dollforum.com/forum/download/file.php?id=1289698&t=1)
(https://dollforum.com/forum/download/file.php?id=1289700&t=1)
(https://dollforum.com/forum/download/file.php?id=1289701&t=1)
Here are some plain bearings parts I made with my Wen rotary tool (aka dremel) with diamond disc attachment and some files. They are made by carefully cutting stainless steel tubing (purchased on Amazon) into short 1mm lengths. The tubing is:stainless steel tubing 3mm OD 1mm wall 250mm length $5, 5mm OD 0.8mm wall 250mm length $5. These should make around 125 plain bearings (accounting for 1mm+ lost per cut in wasted length of metal). So that's about $0.08 per plain bearing.
These are intended to be 1x5x1mm plain bearings. I mean they are basically like a wheel and an axle with the axle having a hole through the center of it lengthwise. These will go into the last few pulley slots in my Archimedes pulley downgearing system. The last few pulley slots have the highest torque at 16:1, 32:1, 64:1 for the last 3 pulleys landing us on our 64:1 total downgearing goal. Because the forces here are reaching into 27lb range (the final output of the system), ball bearings cannot be used at these tiny bearing sizes because they are not robust enough and not rated for these high forces whereas plain bearings can handle it because they don't have crushable little balls and thin walls and stuff but instead are just two pieces of solid metal and hard to break. Less moving parts and more robust. Yes, they have more friction is the trade-off. So we prefer ball bearings until ball bearings can't handle the torque without being large ball bearings - too large for our volumetric space constraints - at which point we swap to plain bearings to handle the bigger torque while maintaining the small pulley sizes we want.
Note that I constructed this little dremel cutting lineup board out of 5x7mm pcb prototyping boards and super glue. It gets the height of the spinning dremel diamond disc lined up with a little pcb board "table" on which the stainless steel tubing can lay flat and perpendicular to the cutting blade and be carefully fed into the spinning disc to make a near perfect cut. I eventually think I should improve on this board design to add sliders and adjusters and endstops etc because as it is now it is too manual skill requiring and free-handish. That means more time spent filing down imperfect cuts later. But it did the job for the time being. I also bought a 2" miter saw chop saw off Ebay with some abrasive metal cutting discs which I want to try once it comes in and compare it to this setup I'm using now in terms of accuracy. It was called "mini bench top cut off saw 2in" at $38.51. shipped.
-
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.
-
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.
-
(https://dollforum.com/forum/download/file.php?id=1294592&t=1)
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:
(https://dollforum.com/forum/download/file.php?id=1294593&t=1)
(https://dollforum.com/forum/download/file.php?id=1294594&t=1)
-
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.
(https://dollforum.com/forum/download/file.php?id=1296266)
(https://dollforum.com/forum/download/file.php?id=1296265)
-
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.
-
(https://dollforum.com/forum/download/file.php?id=1303618&t=1)
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.
-
I recently had an associate disagree with me that if I push through this phase of the project I'll be home free. He said he thinks the AI relating to robot balance and sensory input and physical execution based on sensory feedback will be the hardest part. While I agree that will be time consuming, I don't think it will be nearly as "hard".
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.
One day later:
As I edit the above writing, 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.
-
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.
(https://dollforum.com/forum/download/file.php?id=1315790&t=1)
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.
(https://dollforum.com/forum/download/file.php?id=1315792&t=1)
(https://dollforum.com/forum/download/file.php?id=1315793&t=1)
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.
(https://dollforum.com/forum/download/file.php?id=1315794&t=1)
-
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.
-
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:
(https://dollforum.com/forum/download/file.php?id=1321204&t=1)
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.
(https://dollforum.com/forum/download/file.php?id=1321206&t=1)
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.
(https://dollforum.com/forum/download/file.php?id=1321207&t=1)
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.
(https://dollforum.com/forum/download/file.php?id=1321212&t=1)
(https://dollforum.com/forum/download/file.php?id=1321213&t=1)
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.
-
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.
(https://dollforum.com/forum/download/file.php?id=1333415&t=1)
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.
(https://dollforum.com/forum/download/file.php?id=1333417&t=1)
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.
-
(https://dollforum.com/forum/download/file.php?id=1359064&t=1)
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!
-
(https://dollforum.com/forum/download/file.php?id=1359539&t=1)
(https://dollforum.com/forum/download/file.php?id=1359528&t=1)
(https://dollforum.com/forum/download/file.php?id=1359529&t=1)
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 don't 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:
(https://dollforum.com/forum/download/file.php?id=1364454&t=1)
Here's a closeup detail photo of one of the pulley downgearing stations pictured above:
(https://dollforum.com/forum/download/file.php?id=1364473&t=1)
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:
(https://dollforum.com/forum/download/file.php?id=1364456&t=1)
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.
(https://dollforum.com/forum/download/file.php?id=1365334&t=1)
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:
(https://dollforum.com/forum/download/file.php?id=1365828&t=1)
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.
-
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:
(https://dollforum.com/forum/download/file.php?id=1366435&t=1)
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.
-
The Dinah robot is coming along well. I modeled the full steel skeleton in CAD to match the dimensions of the Dinah base mesh and created a human bones variation as well to compare that to the steel simplified skeleton and make sure all the joint pivots matched the locations of the human skeleton joints pivot points. With this CAD, I will be able to modify the proportions of the steel skeleton I have on hand. I also added several key additional joints using reference photos of a skeleton I found online. For example I now have 2 pivot points for the knee joint instead of one which gives more clearance when knee bends back. I also gave a few more degrees of freedom to the neck and shoulder area. Here's the CAD:
(https://dollforum.com/forum/download/file.php?id=1368700)
Note also that I am well on my way to finishing up printing ABS solid infill fingers and wrist bones which I will retrofit onto the steel skeleton so that I can have full 27 degrees of freedom robot hands and wrists to match perfectly the dexterity of the human hand, which is a must.
I have decided that once I finish the arm and head, I will not go on to complete the building of the rest of the robot's body but instead will switch my focus to the AI entirely from there forward. I will code the AI to cause that arm and head to build the rest of its own body.
-
I managed to get Dinah's hand bones printed out in ABS on my Anet A8 3d printer the past couple days. I also cleaned up the prints, removed the supports, and sanded down high points. They are ready for attaching them together with cloth tape which will act as artificial ligaments.
(https://dollforum.com/forum/download/file.php?id=1369236&t=1)
You'll note I fused the ulna and radius bones together to use as a rotational joint for the wrist to function like a human wrist. The actual pronation and supination of the forearm though will happen by way of the steel skeleton having a rotating pivot point unlike the human body where the radius rotates and twists over the ulna in a criss cross.
Note: in this photo the middle finger is missing the distal tip which I was reprinting as the time of this photo.
-
In these photos you can see the progression of going from the stock wrist to an axial rotating wrist assembly acting as a plain bearing. Pardon the Orgrimmar welding - it's a cheapo welder.
(https://dollforum.com/forum/download/file.php?id=1369626&t=1)
(https://dollforum.com/forum/download/file.php?id=1369627&t=1)
(https://dollforum.com/forum/download/file.php?id=1369634&t=1)
(https://dollforum.com/forum/download/file.php?id=1369630&t=1)
(https://dollforum.com/forum/download/file.php?id=1369631&t=1)
(https://dollforum.com/forum/download/file.php?id=1369639&t=1)
The process involved cutting the bolt head off then grinding smooth the threads and then sliding on a stack of washers and welding the last couple washers into a mushroom head end stop then welding the other washers to eachother and these ones are to spin freely. They will do the pronation and supination. This replaces the need for a ulna and radius for that purpose, simplifying the skeleton some.
The metal outcroppings I left on the washers were meant to jut out significantly to give the fiberglass something to bite onto well for a dependable attachment.
Note: The stock skeleton does rotate axially already at a spot just near the elbow but that rotation is stiff and requires significant force to get it to move and loosening it is something I don't know how to do. I don't even know how it works at all. Advice on that for future reference would be helpful.
Note: There is too much clearance on the stack of washers so they can slide distally or proximally a good 8mm which is not okay - too much play. I need to fill that gap and lube it all with white lithium grease.
Note: I'm planning to probably just go fiberglass wraps over and over onto the stack of washers to grip it tightly and build outward from it and then go out and around the welded mushroom cap and then wrap onto the ABS wrist ulna/radius fused section.
Also note that I have reconsidered adding a dual hinge to the elbow joint and lean now toward just leaving it stock. I think the double hinge would add complication to the bicep attachment and cause some issues I'd rather avoid. A single hinge is easier to deal with IMO.
-
So I finally got the wrist done. And aside from grinding off welds on bolts and backing off the bolts to allow for free movement at joints, I'm mostly going to try to keep this skeleton stock for the most part. So I may be attaching the hand and going immediately into electronics rather than fiddling with the skeleton adding more range of motion here and there. I can always add that later anyways. And in fact the poseable joints that are fairly stiff I'm finding is actually pretty convenient while working on it so I may only free joints on an as needed basis for testing electronic actuation of that joint. Until then I'll leave them alone.
Also note: I was planning to have the wrist rotate axially around the location of the wrist for the pronation and supination. However, I realized this will not look right since you can visibly see the forearms move and the muscles there moving when you pronate and supinate your arm. So I have to have the pronation and supination be where the skeleton was originally doing this near the elbow. This will allow for much more natural looking pronation and supination. So the wrist location will not rotate AT ALL after all. This made it all the easier to make the ulna and radius distal wrist joint where the little wrist bones and hand will attach to and rotate on. I sculpted it all in fiberglass and super glue with some nails and some ABS plastic pieces and epoxy to build up the shape. I used my ABS 3d print of this part as reference only. This thing needed to be very strong as it's likely going to the point of failure as the rest of the arm is steel. So I wanted to make sure it was maximally solid and didn't fully trust just going with a 3d print there.
(https://dollforum.com/forum/download/file.php?id=1371509&t=1)
(https://dollforum.com/forum/download/file.php?id=1371510&t=1)
(https://dollforum.com/forum/download/file.php?id=1371511&t=1)
-
I'm currently working to sew all the finger and wrist bones together for the Dinah robot and mount them to the arm. I wanted to show how I'm doing this process.
Here I tape the bone with adhesive transfer tape 3M 300 LSE. Note that I leave space on either end of the bone to allow some free fabric which is necessary to allow for elasticity as the bones need to rotate after all. Have to have enough free fabric to stretch as the joint rotates, allowing the rotation. But not so much free fabric that the joint is loose either. Has to be just right and snug.
(https://dollforum.com/forum/download/file.php?id=1372870&t=1)
Next I wrap the compression workout shirt fabric onto the tape and cut it to size. Here is just a rough wrap that hasn't been cut down to size yet.
(https://dollforum.com/forum/download/file.php?id=1372871&t=1)
Then here is a bone finished on the sewing and ready to attach to a neighboring bone. The sewing is done with nylon upholstery thread and a curved suturing needle and a surgical pliers using a suturing technique.
(https://dollforum.com/forum/download/file.php?id=1372872&t=1)
-
Okay, so I finally got the Dinah robot hand sewn in and it is looking pretty good. The fingers could use some tweaking but overall I'm quite happy with how it came out. It's solid and fully articulated.
Here's a photo of it in place:
(https://dollforum.com/forum/download/file.php?id=1373847&t=1)
Now that out of the way, I want to announce I'm officially canceling the Dinah project as far as its current goals and here's why: so basically I was thinking it would be nice to just crank out a working robot using some shortcuts and just do something quick and dirty as a learning experience side quest to get something going. It seemed reasonable at the time. Plus I could pace myself to match the build pace of a fellow roboticist and loosely follow his project's designs. But some things I missed in this decision: #1) I'd be lowering my commitment to excellent quality with no shortcuts - ignoring the adage "do it right the first time" #2) by cutting down on workmanship maxing, I'd be inviting harsh criticism on the new lowered bar of build quality which is the last thing I need when already inviting heavy criticism for a extremely ambitious set of goals to begin with #3) I'd be going against my outspoken commitment to campaign against loud metal gear noise based robots that are completely impractical for home use due to sounding like a construction site #4) it would take away from the focus on my "real" robot projects by creating a "ghetto" side quest robot that could have just been skipped altogether. #5) this would in turn delay me truly solving downgearing by pulleys and actuating the robot arm silently once and for all, proving it can be done and proving that achieving a fully human level DOF human hand and arm while maintaining a human form factor and making all of this silent can and should be done for humanoids.
So is Dinah robot just trash now? No. I still plan to have this project be done, but like Adam, it will be shelved until such a day that the other robots, when ready, complete building these shelved robots for me. And when they are built, it will be using the best methods I have including silent BLDC motors with silent pulley based downgearing. So I'm returning to work on the Abel robot whose arm will build the rest of his own body and then he will build the Adam, Eve, and Dinah robots for me.
-
Here is a progress update on the silent pulley downgearing system I came up with using thumb tacks and a #2 fishing crimp sleeve and little plastic discs. It is some tiny fine precision necessary work but I'm getting it done and things seem to be looking pretty good so far.
(https://dollforum.com/forum/download/file.php?id=1373849&t=1)
(https://dollforum.com/forum/download/file.php?id=1373850&t=1)
For now, I ended up just using 401 glue to glue the thumb tacks down onto post it note paper. I then put another coat of the glue over the tops of the thumb tack heads to secure it further. I am planning to use nylon upholstery thread lashings to lash all the tacks down onto the top of the 2430 bldc motor tightly and glue the lashings down as well in order to make the thumbtacks even more solidly set into place. Now I'll grant welding them down would be ideal, however, not having a micro tig welder made yet (future project), I just wanted to get going fast and I thought with enough care, it is possible these can be constructed solidly enough with composite material techniques to function reliably. I'm crossing my fingers. We'll see.
-
I got done cutting out the pulley discs and drilling them and mounting them to the thumb tacks and gluing them in place with 401 glue using a sewing needle tip as the applicator. They all are reasonably square and solidly in place I think. Everything is moving freely. Everything seems lined up okay. I then mounted them all to the 2430 bldc motor.
(https://dollforum.com/forum/download/file.php?id=1374948&t=1)
These thumb tack based pulleys still need to be lashed down well and the lashings (upholstery thread) need to be coated in 401 glue to make them stiff and solid. I also need to add pulley discs to the 2430 bldc motor that are to line up well with the pulley disc slots the string is to go to. I then need to wind up the string sections themselves, loading up the system in preparation for actual testing.
-
I wound up my 6lb test Hercules PE braided fishing line onto the previous pulley system setup only to find out that the pulley could only handle about 21 inches of fishing line wound onto it before it started to come dangerously close to overfilling the pulley. The aim is to have plenty of the plastic disc overlapping the fishing line even when it is wound up fully to one side because that plastic disc acts as the guide to keep the line in its proper channel. I want at least 32:1 mechanical advantage out of this downgearing so if I want my final output to be 1" then the first pulley has to be able to wind 32" of fishing line onto it comfortably. So I realized at least the first pulley has to be a few more millimeters increased in diameter. So I had to rebuild the thumb tacks arrangement to accommodate these changes and make that first pulley bigger.
(https://dollforum.com/forum/download/file.php?id=1376125&t=1)
(https://dollforum.com/forum/download/file.php?id=1376126&t=1)
With this increased size first pulley, I realized I'm getting what looks to be 7:1 mechanical advantage from just the first pulley alone! At least initially when it starts. As the fully wound up pulley gets winched in by the motor, the relative size differential gets smaller which means it will speed up and the torque will be less than the starting torque and increasingly so as the size differential decreases. This will create a natural sort of acceleration effect and high initial power and gradually less power. I think these side effects of this system seem to be quite good but I'll know for sure in testing. The next steps will be to wind up the reverse direction of the first pulley and start connecting the first pulley to the second pulley and so on. I may not even need all 5 pulleys but we'll see. With the first pulley being already 7:1, if the remaining 4 are 2:1 say, then we'd have 7:1, 14:1, 28:1, 56:1, 112:1 so 112:1 would be the final output. That seems quite overkill and perhaps will be too slow. Although very strong. The motor outputs about 0.42 lb on average so .42*112= 47lb! Now the lever of the joint itself makes you lose mechanical advantage due to the fulcrum location etc so it would drop down to say 15lb but my finger individual joint flexion power is only like 5-7lb so that's double mine. So a bit overkill. So I might skip using one of the 5 pulleys. Having it there is nice though just in case we wanted to trade speed for power for some of them we'd then use that one as an optional strength boost we can tap into in the future if we want to trade speed for strength so I might just leave it in the design even if I don't use it just yet. In testing I may find I prefer to use it afterall. Nice to have that option if needed.
-
So it turns out that when the forward and reverse directions portions of the thumb tack pulley downgearing system are doing their thing, they won't always have the same mechanical advantage and so will be moving at different speeds. Therefore, I have to treat the forward and reverse pulley systems as entirely separate systems that have to be completely decoupled and handled independently, each pretending like the other one doesn't even exist. They can share the same thumb tack, but have to be decoupled. So I cut the #2 fishing crimp sleeve in half using my miter saw and have to redo the plastic discs phase.
(https://dollforum.com/forum/download/file.php?id=1376802)
Each half #2 fishing crimp sleeve will have 3 plastic discs, one for outside of the larger diameter pulley and one for the outside of the smaller diameter pulley and one to split the two. Three total. And so with 3 plastic discs on each half crimp sleeve we have 6 total discs per thumb tack. We only had to deal with 5 before so things will be even tighter but it's fine. We have enough room.
Next, since both sets of pulleys have different speeds that vary over time, the one that is not being actively winched in at any given time will be randomly releasing slack in a chaotic way. This can lead to tangling and all sorts of problems. To resolve this, we need a automatic slack tensioner system to aid the pulley system by keeping this releasing group of pulleys in a state of good tension at all times. This I will resolve by the pictured method.
(https://dollforum.com/forum/download/file.php?id=1376806&t=1)
So basically a tension spring connected to a metal eyelet will at all times be trying to pull the fishing line out of alignment and draw slack out of it. So as looseness is detected, it will immediately draw that in removing it from the system maintaining taughtness everywhere at all times. This will prevent the pulleys from getting tangled or anything like that. This setup can be placed anywhere in the path between the pulley system and the joint the pulley system is to actuate.
-
(https://dollforum.com/forum/download/file.php?id=1378589&t=1)
(https://dollforum.com/forum/download/file.php?id=1378599&t=1)
I started some testing on just the first pulley and lots of things went wrong:
Twice I had to increase the pulley size because I wasn't able to use enough line winding onto said pulley for my total line draw need after accounting for the 32:1 downgear ratio. I calculated 27" as the very least it has to winch in at the motor shaft to get 0.84" total draw at the joint of the index finger which is perfect (27/32=.84). The pulleys were too small to accommodate 27" winched onto them so I had to increase the size - which meant removing everything, increasing size, then rewinding everything by hand for an hour plus! Just so tedious and annoying!
Another failure was one time, the string was too loose on a pulley and a tighter wrap got under the looser wraps and then the looser ones snugged against it binding it down like someone said would happen - which made it all stuck. Also I had many derailments where the string came off the pulleys and started wrapping up on the axle off all the pulleys and getting things quite stuck that way. I've been dealing with carefully untangling and rewinding tangled messes over and over. It's been a disaster. I thought of scrapping the whole thing a couple times.
However, after taking a step back, it occurred to me that the tangling issues were largely due to forgetting to put the final outlet of the system under load to tension the whole system which would keep every pulley winding nice and tight and aligned well. So this was user error and oversight, not the fault of the basic concept of the system then. I just forgot to do those parts in my rush to start testing things. I planned to only add that stuff at the very end once the whole system was done and did not think I needed to do that just to start initial testing on a single pulley. That was a faulty assumption and an oversight. The whole system always has to be under tension to work right. My bad. Lesson learned and a valuable one at that. I did not fully grasp until I saw with my own eyes the disasters the importance of keeping it all under tension at all times. Yes I knew theoretically it was needed eventually, but I did not realize the whole thing was absolutely doomed instantly every time if it is not immediately under tension even for a first set of simple tests. That was revelatory for me.
I'm glad I got to see the failures first hand though because it enabled me to study what failures can be expected when tension is not placed and know intimately first hand the importance of tension and how lack of tension causes the failures specifically. Valuable to see it with my own eyes instead of only imagining it. This has helped me come up with some cool derailment prevention and loss of tension prevention mechanisms to fool proof my system more - even beyond the tension spring drawing shown in my last post.
Note: At the top of the motor output shaft, you can see two large pulleys where I have wound 2 pulleys for moving the motor axle clockwise and counter clockwise to simulate the motor moving. These are temporary windings just for testing manually without messing with electronics for now. These need to be fed in under tension at their inlet and their inlet needs to have a eye positioned in front of it that forces the string to stay in line and not feed in astray out of alignment. So also the pulleys for the main motor output shaft pulley for flexion I'm testing and the first pulley downgear I'm testing. Every place a string enters a pulley needs to have a small eye that guides the string onto the pulley perfectly in alignment with the plastic discs of the pulley and prevents it from derailing.
I noticed that when feeding string into a pulley I intuitively hold the string between thumb and index finger and pull the string away from the pulley as its being fed into the pulley to apply tension on the line and tight wraps on the pulley. I also align the string with the center of the pulley and hold my fingers at a minimal distance away but not too close. You want the string to be able to easily angle up and down from your finger pinch point to ride up and down the height of the pulley creating layers of wraps evenly as opposed to all wrapping in one area and not having a well distributed wrapping. If you study how to wind a bobbin on the top of a sewing machine, you see the string take 3 turns and go through a metal wheel that places tension onto it and only then does it enter the bobbin which it then winches onto the bobbin rapidly to wrap up the bobbin with string. These are all designed to create tension from the otherwise loose and floppy string leaving the main spool of thread you are feeding into your empty bobbin. I need to create a similar type of tension system to feed onto my pulleys which are acting just like that bobbin and need the same type of setup to succeed.
To create the eye that centers the string and forces it to neatly stay on the bobbin and not derail so easily, I plan to use 28 ga tinned copper bus wire. I will cut out a small section of that wire and glue it to the base platform the thumb tacks are glued to and then run it vertically and then form the eye shape that acts as a guide and derailment preventer. The eye will just be a oval with a couple legs glued down with 401 glue to hold that oval into position.
(https://dollforum.com/forum/download/file.php?id=1378600&t=1)
For the tension maker, I'm planning to use just a couple windings of tension spring with two small square pieces of plastic which will sandwich together and be pinched together snugly by the tension spring and the fishing line will be fed through this. I will use the same produce container plastic I'm using for the pulley discs. The fishing line will not be abraded/damaged by this in theory but only some pinching force applied to it to give it some tension and cause its feeding action of winching onto the pulley to be tight and snug to help prevent derailments and tangles and loose wraps. This system is meant to emulate and replace holding the string snugly between thumb and index finger as it's fed into the pulley tightly.
(https://dollforum.com/forum/download/file.php?id=1378585&t=1)
Note: I'm not surprised I'm having these issues. The system was not under tension with the spring tension system I posted in my last post yet so that's largely why this is all happening. These measures are mainly resolving issues caused by that lack. However, by adding these problem preventers into the system, I make the system more redundantly protected from any issues coming up in the future. It's like backup systems for problem prevention here.
Note: thinking back to the tremendous struggles and trial and error I watched the engineer on the YouTube channel "StuffMadeHere" has been an encouragement to me in this struggle. His videos never really have just perfect flawless success the first test run. There is always problems and tons of trial and error tweaking to resolve each issue and creatively work around it until he ends up with these beautiful and elegant solutions in the end that work great. This seems par for the course so I just have to remember that this type of headache phase is typical.
Note: it is VERY tedious to have to untangle messes I've made due to lack of tension and proper guidance etc for the string windings. We have 5 total windings each around 3 feet long and all within a envelope close to the area of my thumbnail. It's all compact and tedious and little precision needle nose tweezers or the tip of a sewing needle is the only stuff small enough to even get in there to grab anything. Just a overwhelming mess to fix issues. Not for the faint of heart. If I did not believe this has strong potential I'd give up but everything so far isn't proving lack of merit but moreso is user error and not having a good setup going yet. But even that is a good thing as studying the error and causes of error is giving me great insight into what needs to be done to prevent future error and make the system reliable. I need this first hand education to preempt future errors.
-
I managed to implement a friction device for both main manual input pulleys for manually turning the motor shaft and one for creating tension on the system at all times. The former I made by just running the fishing line through a tension spring between the coils which pinched the fishing line enough to provide friction and feed it snugly into the motor shaft as it winches it. This successfully replaced the need to feed it in by hand between thumb and index finger with snug pinching action to get it to winch in tightly. For the tension on whole system need, I ended up just hanging a bolt from the final output string which put the whole pulley system under light tension.
(https://dollforum.com/forum/download/file.php?id=1379619&t=1)
You can see the tension springs sewn into the bone fabric on the left hand of the pulley system in the attached photo. You can also see the thread going through those if you look carefully. You can also see the output pulley on the right hand side of the system and see the little metal 28ga wire eyelet I made and the string being fed through that eyelet as it heads toward the camera lense shooting the photo. It then drops down out of sight. So you have to visualize it tied to a bolt. The bolt is currently taped off to a piece of bone since I removed the tension after testing to do some repairs.
So to the results: with these little modifications, the testing went much better. It was fairly reliable. The only times anything tangled up was when the bolt caught on something when I wasn't paying attention which relieved the pulley system momentarily of the tension created by the weight of the bolt pulling down by gravity and tensing up the system. As soon as the system lost that tension, it began to unravel and created a tangled mess. This happened a few times in testing and was user error. Although one time a pulley just stopped turning randomly despite the tension created by the bolt. That concerned me alot. I don't know if something got wedged in it or it was cockeyed just right or what but sometimes it gets stuck a bit. That cannot happen ever or the whole thing fails. Perhaps greasing the inside of the fishing crimp sleeve would prevent this from happening anymore. Also, the bolt is not THAT heavy. Using something with a bit more tension force placed onto the system could also help some more perhaps. I think using a tension spring as the tensioner - as shown in a drawing I posted previously - will be just the right amount of tension. I think it might pull a bit harder than the weight of the bolt was pulling. So between those two improvements I think this rare fluke will be avoided. And so far, as far as I've seen, as long as the pulleys spin freely and no tension is lost, everything appears to work perfectly. I was able to go back and forth with no issues many times besides the few screw-ups I already mentioned.
So the system appears to be a success so far from testing. I can now move onto building pulley #2 and 3 and testing them thoroughly in conjunction with pulley #1.
Also of note: I thought pulley #1 was a 3:1 ratio and perhaps it is at times, but the mechanical advantage ratio changes over the course of the winching process because the larger pulley gets smaller as it unwinds and the smaller pulley gets bigger as it winds up. So their relative diameters changes. Therefore, I guess we have to treat it as what is the average mechanical advantage it produces. Well in the final measurement, it cut down the original 27" of string being winched in to 13" of string on the final output. Trading down that distance of travel is the key to the creation of mechanical advantage.
We want the final output to be around 0.84". We want 32:1 mechanical advantage in the end. So pulley #1 got us to 2:1 mechanical advantage only so far. The next pulley likely will get us to around 4:1 and the next one 8:1. I am considering just stopping there. I have room for two more pulleys, but at the moment I'm considering doing the last two down-gears with my Archimedes downgearing pulley design. I think that method might be a little more robust and I kind of just want to use both methods at this time. Both have their pros and cons. I feel using both methods can help me learn which one is superior and learn to perfect both as I see which one is more durable long term, which one has more incidents, which one tangles from time to time and why and resolving those issues if they come up.
The great thing is this: the compact pulley method (thumb tack method) is giving us 8:1 downgearing roughly. Of the 27" of total draw, that brings output draw at that point down to 27/8=3.37". So the final two downgearing stages will be reducing 3.37" draw down to 0.84" draw. So 3.37"/2=1.68" then 1.68/2=0.84". So the Archimedes pulley system only needs TWO pulleys (down from whatever huge number we had before in our previous monstrosity of wraps and turns we had to do). To make just two pulleys is a piece of cake. Also, given 3.37" is all we are working with for the first pulley, and the pulley is equidistance in the center of that stretch, the total draw length of the two string halves wrapping around that first pulley is only 1.68". And the next pulley's total length is .84". So 1.68+.84=2.5" give or take is the total length of the pulley system for this. This edition of the Archimedes pulley system adds 4:1 downgearing to the compact thumb tack pulley system's 8:1 downgearing. Giving us a total of 8x4= 32:1 downgearing. That 2.5" total length Archimedes pulley system setup is so small compared to my original 16:1 Archimedes pulley system I published earlier that it is a lot more practical to use and we still save a ton of space.
Note: I could do the rotate in place style pulleys but just put them on the forearm instead of the motor as the motor is already getting quite cramped and tedious to work with. Or I can do Archimedes pulley system style with pulleys that move lengthwise along the forearm. Both styles are good. I lean toward the latter though at this time. Both would work though. I kind of just like the variety for learning purposes but I'm not 100% sure on this decision.
Note: an advantage to completing the final 4:1 downgearing on the forearm closest to the finger joint is the total distance of string travel from the motor to the finger joint and the total bends it takes all adds friction and when that friction is placed with a large force on it, it is harder on the teflon guide tubing. But by only doing partial downgearing at the location of the motor and saving the next phase of downgearing for being closer to the finger joint in question, we avoid a lot of forces and frictions in the teflon guide tubing running longer distances to get to the finger. In some cases, I have motors intended to actuate finger joints placed in my CAD as far away from the finger joint as the upper spine area and some in the lower latimus dorsi area! That is a LONG travel to go across the torso, past the shoulder, down the humerus, past he elbow, down the forearm, and then FINALLY to the finger joint it is actuating. That is a LOT of friction and turns introduced. So to navigate such long distances, it is ideal to have it be just high speed low torque during that time-frame and only beef up the torque with downgearing NEAR the finger joint it is actuating.
Note: the fishing line selected for downgearing while in the early phases of downgearing gets to be very fine low test strength fishing line like the 6lb test braided pe fishing line I'm using here. However, as the downgearing progresses, trading speed for torque, so also the fishing line selected for these sections needs to progressively get larger in diameter to accommodate the higher tensile forces involved. So we'll be graduating from 6lb test to 20lb test then 70lb test then 130lb test. So we'll be changing fishing line diameter 4 times in the routing from the motor output shaft to the joint itself! That said, keeping the downgearing near the motor minimal is best since it enables us to use the finer diameter fishing line for the long travel distance from the motor to the finger area. Then only once near the finger do we do the final downgearing stages and beef up to the larger diameter fishing lines. Then another advantage to all of this is the teflon tpfe guidance tubing we are using as guide tubing gets to be smaller diameter guidance tubing for those long fishing line runs. This saves space and enables us to make tighter turns without as much consequences in terms of wear and tear on those turns and tension/friction concentration at those turns. Also, when making turns AFTER full downgearing, the higher forces involved tend to want to crush and deform the TPFE tubing - which is why sometimes metal spring is used on the outside of the TPFE guidance tubing to make it into a Bowden cable and reinforce it to make it non-collapsible under the high tension forces that get involved by that point. We avoid all of this by keeping the downgearing at the location of the motor more minimal.
Note: that all said, our downgearing at the location of the motor thus far is planned to be 8:1. The motor outputs .45lb at our distance from the center of the motor shaft roughly. So 8x.45= 3.6lb of tension force as the output at the motor then. This means we get to use our 20lb test fishing line for the long travel from the motor to the distal forearm where we will do the final 4:1 downgearing bringing us up to 32:1 downgearing. That 20lb test line is only 0.2mm diameter so it and the TPFE guidance tubing we pair with it is very fine and can easily weave its way past everything and get to the distal forearm without taking up too much space or having to be reinforced by metal spring to prevent crushing or distortion of the TPFE. At least not in theory. If this proves not true, I can always add metal springs to any sections that are getting crushed or distorted to reinforce the outer diameter of the TPFE guide tubing in those areas - probably areas near tight turns? We want to take as few turns as possible though and make the turn radius as large as possible to cut down on friction as much as we can during the fishing line routing runs.
-
(https://dollforum.com/forum/download/file.php?id=1380284)
This is a slow, careful hand test of the pulley. Everything looks good. Also, I did fast tests but didn't capture a nice shot of those with good hd closeup like this. In any case, this can show you some idea of how it all looks in action so far. The motor shaft is not turning electronically but is being turned by me pulling string wrapped around it to screen left is my hand pulling. To screen bottom is a hanging bolt that is being winched (not shown its cropped out of the image).
I wanted to avoid working on the electronic actuation which is a rabbit hole in itself until I have the pulley system fully done and tested. THEN I will make it all work electronically as the next phase.
-
After further deliberation, I have concluded that I should put 4:1 downgearing on the motor's top with the turn in place pulleys and put 8:1 further downgearing located nearer to the joint being actuated - in this case the distal forearm. My reasoning for this is as follows: the routing from motor to near the joint is facing turns and friction etc and these become smaller factors when under lesser loads. So leaving things more high speed low torque initially during this phase of the routing is advantageous to lower friction and issues relating to deformation and compaction on the guidance tubing. This means less wear and tear and lower maintenance as well. Next, the turn in place pulleys are quite difficult to work with being very small and compact and lots of winding and whatnot is hard to deal with and tedious. Further, the turn in place style, when fully winched in has a much lesser downgear ratio compared to when fully extended due to the relative diameter size ratios of the pulley pairs involved changing in size during the winching. Whereas in the Archimedes pulley downgearing system the mechanical advantage is fixed and doesn't change during the entire flexion nor extension process. This makes it more reliable and limits our losses during the near end of the winching phase that are incurred in the turn in place technique. This ensures we retain adequate mechanical advantage during all times.
Another important update is I have added axial rotation to the proximal finger joint in CAD. My index finger has a little bit of this type of control to it so I think it will be a nice boost to control and dexterity for the robot. Really maxing out the ability of the robot to finely manipulate its finger positions and improve performance of the fingers at all tasks. I added the necessary 4 additional motors to achieve this into the CAD as well. You can see the highlighted pair of axial rotation red indicator arrows which show the angle and location of the tendons from where they terminate to where they will exit the guidance tubing - the range of motion if you will.
(https://dollforum.com/forum/download/file.php?id=1381829)
Yet another important update is I now plan to just use a spring for the extension actuation force rather than the reverse direction turning of the motor. This is admittedly going to give the extension less strength and the flexion less strength. The flexion will have less strength because it is now fighting against the extension spring to get the finger to flex. The extension will have less strength because a spring alone is making it happen rather than a strong motor making it happen. I don't mind either of these trade-offs though because it will greatly simplify the routing - cutting it in half, simplify the motor mounted pulleys, cutting it in half, and simplify the Archimedes pulley systems, cutting the amount of them we have to make in half. That is just a massive amount of time and effort saved. I just am not convinced that spending that level of time and effort just to have a stronger extension of the finger joints is worth it. Relatively passive spring powered extension of fingers is very common in hobby humanoid robot hands from what I've seen and although I've always viewed it as a lazy solution, I do see some merit in embracing more simplicity at times. Especially if you cannot JUSTIFY the added work of the alternative. The more I think about when I have needed finger extension to be very strong, the more I find that it seems to be a relatively rare occurrence. It just doesn't seem to happen often. Now as the robot grows more able with its AI and more sophisticated, and gets into more and more types of work, the occasional scenario where fully powered extension of fingers will start to crop up more and more as a need. So at that time, I am thinking we can revisit this and get the extension actuation installed. So I still plan to reserve space for it on the CAD and ensure it can be done without any major problems or redesigns needed. It should be a smooth and straightforward upgrade option. But for a minimum viable product that can meet all of my goals, it is not necessary to implement in this stage of development. In fact, it is also possible to just have the robot install these on himself once he's building the rest of his own body. Which means me doing it would be a waste of time if the robot could do it later instead of me. So in any case, this acts as a MAJOR shortcut and time-saver for me and will be a big game changer IMO. I'm excited about it. These types of big shortcuts really move the project forward in development very rapidly in large leaps saving countless hours and I love them. As long as they aren't shortcuts that will come back to bite us later, I'm okay with them. I don't think this one will bite us later so I say let's go with it!
Note: it also just occurred to me that the robot could potentially have the extension actuation be in the form of geared n20 motors instead of reverse direction of the main 2430 bldc motors with pulley based downgearing. This would save alot of work but introduce noisy metal gearing to the robot. The reason I think this is okay to do is that these geared n20 motors would be slack lined and not interfere with fingers AT ALL nor be used on any way at all UNTIL the fingers need strong extension actuation - which as I said is incredibly rare. In this rare event, it tapping into these geared n20 motors for some extra oomph to get the extension to actuate harder would solve the problem and the little noise it created would be a rare occurrence type of noise. It would hardly be noticeable then and 99.999% of the time you'd never encounter this noise. The bigger issue would be noise in a common feature like blinking. Now THAT is annoying to hear gears EVERY TIME the robot blinks.
-
I have added the final pulley and rigged the guidance TPFE tube up to that pulley and routed that to the general vicinity of the Archimedes pulley downgearing system. As seen in the photo, I used super glue and post it note paper to form a TPFE guidance tube support structure to hold it in place as well as wrapped it in fabric tape and soaked that tape in super glue. I applied the super glue with the tip of a sewing needle as a precision application method.
(https://dollforum.com/forum/download/file.php?id=1381891&t=1)
The next step will be to test the pulley system as is and make sure everything is working really well.
If all testing passes, we will then modify the Archimedes pulley system on the forearm that we were using before to simplify it some since it now deals with only 7" or so of string compared to 27" of string it dealt with when we did not have the turn in place pulley system in place. So it will now be much more compact and fewer pulleys needed in it. So a bit of redesign and part recycling and we'll be good to go on that. Also, before, it was a 16:1 Archimedes pulley system whereas now it will just be a 8:1 system.
-
I just ran a test of the second turn in place winching pulley and ran into several problems. First I noticed my main lines turning the motor were not the full 27"+ which I thought they were but just remeasured and found they weren't. My bad. So I have to rewind those to fix that. Next, I noticed that just as we depart from the motor output shaft we experience mechanical advantage with each downgearing, so also when traveling from the downgeared area back to the motor output shaft we experience mechanical disadvantage. Up-gearing. Which means the bolt hanging as a load to place tension on the pulleys during a release cycle was not enough weight anymore (was barely enough before now clearly not enough). Now note that the bolt represents what a tension spring will normally be doing, tensing up the winch system to keep it all solid and tight. I don't want this to have to be much heavier than the bolt. I want the system to not need much pulling to remain good in tension. The friction of the teflon tubing plus mechanical disadvantage etc was causing the pulleys to not remain tense (and their not being lubed yet on the junction between fishing crimp sleeve and thumb tack. So my solution I'm now contemplating is either moving one of the turn in place winches down to the location of the Archimedes pulleys on the forearm area and putting the tensioner apparatus between it and the previous pulley mounted on the motor so that the tensioner apparatus does not suffer as much mechanical disadvantage due to up-gearing OR I get rid of the second pulley entirely and just have the winch in place be a single pulley 2:1 and the Archimedes system be 16:1. Which still works as we have then 32:1 which is great still. Under such a system, the original 27" winching would be reduced to 13.5" by the winch in place pulley attached to the motor. The Archimedes pulley system then needs to go down, around one pulley, back up, around another pulley, then down and around another pulley, then back up and tie off. The total travel for those one down, one up, one down, one up (4 trips) is 13.5/4 so 3.4". And we'd sit at 8:1 at that point. so adding two more pulleys beneath that first group would add another 4:1 for 32:1 total. And those two pulleys would add another half inch tops so that gives us around 4" total length of the Archimedes system and not too crazy many turns in that first system like we had in our first prototype. Still quite simplified comparatively speaking. So this is a very viable solution. And that 4" is around 10cm and we had 11cm already planned for this purpose in the CAD in the forearm from before. So we are still within that target and viable still without any change to the CAD at all which is great.
Anyways, back to the test's issues discovered. Oh yeah, also, the load (in this case a bolt hanging) struggled to keep the turn in place winches under tension while the motor was releasing the bolt (loosening or unwinching itself) not only because of the mechanical disadvantage from the pulley upgearing itself and from the friction in the TPFE guidance tubing but also from the friction of yet another pulley and its friction between its fishing crimp sleeve and its thumbtack. So I was having to manually pull down assisting the bolt, pulling down fairly hard just to get the system to stay taught and release without becoming a derailed tangled mess.
One other work around if I were insistent on going with more than one winch in place pulley would be to wind up extra line onto each turn in place winch pulley and have that directly attached to a tensioner spring placed wherever on the robot. This would always keep tension on just that winch in place pulley and be responsible for just that pulley and suffer no mechanical disadvantage beyond the TPFE guidance tubing it has to pass through to get there which shouldn't be too bad if the spring can be nearby. This is a valid solution but adds another layer of complexity to the winch in place pulleys and now more routing and string to deal with. It also means loads of extra springs to place. Attached is a drawing of the proposed tensioning mechanism for tensioning each pulley individually.
(https://dollforum.com/forum/download/file.php?id=1382415&t=1)
In any case, were I to add this type of tensioning apparatus to each pulley and the necessary extra plastic disc and vertical spacing to glue string to the fishing crimp sleeve and wrap it up, that takes up even more vertical space in the system and we were already really lacking sufficient space as is. So to gain the extra space needed to do that, we'd have to extend the height of the fishing crimp sleeve to accommodate this which would then remove the option to add the reverse direction set of pulleys to the same thumb tack. Although that is probably fine now that we were planning to achieve that with just a tension spring as the actuator for extension of fingers instead of motor actuated extension and coupling that with a n20 gear motor for extra oomph in demand on a rare as needed basis for extension action when the tension spring is not strong enough to do it for the task at hand (rare). So yeah, this apparatus would work to solve the issues I'm having with my current test setup I think. But just going 16:1 on the Archimedes instead of 8:1 on the Archimedes pulleys and simply deleting the second winch in place pulley on the motor seems like the best option to me right now. Doing so means the Archimedes pulleys bumps up from 27/4 = 6.75" for Archimedes pulleys to deal with 6.75/4 (for up and down passes around first group of pulleys) so 1.68" in length then another pulley brings it to 2.1" total length compared to 27/2 (only one winch in place pulley) = 13.5" for Archimedes pulleys to deal with 13.5/4 (for up and down passes around first group of pulleys) so 3.4" then add 2 more pulleys so 4.2". So 2.1" vs 4.2". If we keep the second winch in place pulley we shave off 2.1" in Archimedes pulley system total length and shave off one pulley from its system too. Well I think just going 16:1 on the Archimedes is my move here. The winch in place pulleys have been a finicky mess to me. I prefer the Archimedes style pulley more and prefer to have that do the lions share of the downgearing after that first winch in place pulley cuts our total run-out in half. It still is a very useful help to cut things in half like that and much appreciated. But any more winch in place action is asking for trouble. I am much less able to control it and prevent issues that I feel I can do with the Archimedes pulley system. And you all have not seen my Archimedes pulley system in action it is really beautiful and elegant to watch and totally silent. So I'll rely on it more and keep the winching turn in place pulleys to the minimum 2:1.
Someone trying to do their own robot may appreciate that I'm leaving these options for further exploration open for future devs. I'm going the way I am most comfortable but if you think the winching method is more comfy for you, downgear more with those than I chose. I am not ruling that out here - just preferring the Archimedes more based on my experiences so far.
-
Ok so I was struggling to plan out how the flat spiral coil constant force spring would maintain constant tension on my first winch in place pulley the past couple days and I was studying how tape measures use these springs. Then it hit me when a colleague was mentioning belt pulley based downgearing that a belt pulley based downgearing for this first pulley would remove all the issues of derailment and need for constant tension during whole duration of travel a winch style would require in this design. Also, since its just .4lb-.8lb of force for the first pulley downgear, as long as the belt is reasonably tensioned and has some decent grip to it, I should not deal with a ton of slippage issues and the motor's output should be passed along well. So here is my beginning attempt at converting my first pulley to a belt based pulley instead of fishing line winch based pulley.
(https://dollforum.com/forum/download/file.php?id=1390661&t=1)
This is made just using adhesive transfer tape applied to one side of a nitrile glove and cut out into a 1.1mm wide strip and applied to the two pulleys directly. Built in place.
Early testing shows it needs more layers to have less stretchiness or needs to be reinforced internally with fishing line wraps between layers to prevent so much stretch to it which causes slippage. Also, the motor output shaft acting as the winch pulley is a combination of a bit too small in diameter and a bit too smooth to create a proper grip. So I'm thinking of thickening it up some and adding a grippy surface to it so that it grips the belt better with less slippage.
I am considering using silicone rubber to coat the motor output shaft or several wraps of nylon upholstery thread and super glue to thicken it then coating that with carpet anti-slip paint. Or silicone.
I'm considering making the belt from a cloth coated in silicone or carpet anti-slip paint and then sewn tightly into place over the pulleys - creating a sewn seam for a tight grip.
I'm considering a tensioner pulley but I think that's overkill and should be avoided unless it proves absolutely necessary.
I have not explored purchasing options at this time but of course I'm open to look into this in the future. The thing about a premade is it would have to be a perfect fit in both length and width and I'm not sure if that will be easy to find or not. This is all a very new approach so I can investigate that later. For now I'm happy to just move quickly on the prototyping with materials on hand.
-
Ok so my belt drive system from my last update just is not quite up to par in terms of grip and anti-slippage. So my new series of changes are planned out and underway now. First, I will be bumping up the height of each pulley to 2mm up from 1.1mm. This will double the surface contact area for way more belt grip in and of itself. So then I can use a 2mm wide belt. Next, I'll be increasing the drive pulley diameter to 1.5-2mm additional diameter. This will also greatly increase surface contact with the belt for more grip. Then finally, I'll be using a commercial belt that is said to have the highest grip of all belts - its called a polyurethane belt. It is a flat belt with 2mm width and .9mm thickness. It should be a huge upgrade to my current setup! Here's some photos of it:
(https://dollforum.com/forum/download/file.php?id=1401776)
(https://dollforum.com/forum/download/file.php?id=1401777)
The best part is you can customize the diameter of the belt by melting the two ends together! This was a key thing I did not know! So I can create just the right size and it should be perfect! I can also double these up by melting two belts layer by laer for a 1.8mm thick square shaped belt that is even less stretchy and so can be even more able to tightly grip my pulleys. I'm very excited about this and think it will take us to where we need to be *crossing fingers*.
-
I've had an epiphany. So in the winch in place pulley system I was working on before, my concern was that when winching in the string things would be taught and reliable but when the motor reverses and releases string, that is when any snags in the system could cause the string to not be taken up rigidly and tension on the system is then lost and the motor is then unspooling string which isn't being taken up which will result in a spaghetti mess of string spraying everywhere out of control and getting all tangled up. The solution I had was a constant tension spring attached to the turn in place pulley output that would ensure that always keeps the string in tension as the motor unwinds. However, that was a extra cost and complexity and volume taken up by yet another thing and when you multiply that out by 300+ motors that's a LOT of springs added taking up a ton of extra space. That is why I moved to a belt based system instead of string and winch based for the first pulley. So the epiphany was this: it hit me that I can simply have the spring that does the extension of the final finger joint be what puts tension on the whole system and then if at any point in the system a snag were to happen, rather than tension being lost as the motor blindly unravels, not detecting the snag, I could have the motor NOT actively unwind anything at any point! So the motor, when unwinding is to occur, will simply turn OFF, rather than actively drive the unwinding electronically. It can pulse width turn off just acting as a brake to moderate speed of extension but at no point do any counter clockwise release or unwinding of the string. This way, the system only itself pulls string off the motor output shaft and if the system at any point snags, the extension stops and the string is all still under moderate tension but just no further advancement takes place and the motor does nothing further but blindly turning on and off but not actually spraying out thread everywhere at all. Eventually, the potentiometer measuring the joint angle of the finger joint would detect things are not moving and the system would KNOW it has a snag somewhere and at that point it would perhaps try to contract then attempt extension again hoping to dislodge the snag. If this did not work, the system would go into a troubleshooting routine like notifying the user (myself) to fix it or fixing it itself or w/e. But no damage would occur in this setup involving a unraveling mess or tangled mess. Simply the snag itself would be discovered and addressed but no catastrophic series of failures would result in theory under this new setup.
So with all of that said, and this solution in place, I am ready to return to the turn in place style winch style first pulley setup I had before and then the Archimedes pulley will do the rest. So the first pulley will be 2:1 downgearing and the Archimedes system will do 16:1 for a total of 32:1 downgearing. No constant tension spring needed anymore! Much simpler now. Everything I was concerned about is then solved now.
The belt based system fix ideas I was going for may have worked but as of right now I'm abandoning that course. I prefer the winch style and think belts would be higher maintenance and slippage would perhaps be an issue even with all the changes I had mentioned to improve on it. The fact is, belts only have so much surface area to grip onto so they don't scale down too well to tiny pulleys IMO. Large pulleys are better due to large surface area and more for the belt to grip. So my super miniature belt idea was a bit doomed from the start even if it could have worked (and it may well have worked) it just isn't ideal theoretically and I'd rather go with something I trust more intuitively for now.
-
Here's my latest progress on the winch in place pulley setup. I opted for 10lb test 0.12mm diameter PE fishing line (orange color) as the output that will interface into the first pair of downgearing pulleys of my archimedes pulley downgearing system.
(https://dollforum.com/forum/download/file.php?id=1416768&t=1)
This turn in place pulley achieves 2.77:1 downgearing ratio now. The motor shaft reels in 32 inches of string that is 6lb test 0.08mm pe fishing line (black) and after the downgearing pulley, the final amount of orange fishing line reeled in is 11.55". That's a much more manageable amount of runout for the archimedes pulley system to deal with to keep it more compact.
The archimedes pulley downgearing system will add an additional 16:1 downgearing to this which brings me to a total of 44:1 downgearing. The motor itself pulls at .5lb pulling force so after 44x that increases to 22lb of pulling power. After mechanical disadvantage is factored in, I estimate the finger can curl 5.5lb ideally which is about the same strength as my finger. So that's perfect and VERY strong IMO.
-
Not the most substantial update but I wanted to share my top cap solution for the winch in place pulley. In this photo, you can see that I cut out a small piece of the clear plastic from strawberry container into a little square and poked a hole in it with sewing needle then pressed it onto the tack firmly till the tack jutted out a bit like 1mm. Then I glued the tack to the top cap with 401 glue. This keeps the pulley from coming off the winch when the motor is upside down which it is now.
(https://dollforum.com/forum/download/file.php?id=1420663&t=1)
Another small update is I just ordered some plastisol to experiment with for robot skin making or even other parts of the robot like the artificial lungs or even ligaments perhaps. I ordered the hard and the soft versions which you can mix together to get medium variants. This is the stuff used to make fishing lures but the harder formulations make pvc medical skeletons. It is a thermal plastic so its like TPU but unlike TPU, not so fussy since you can microwave it for 3 minutes and use it - much easier and lower fumes. You can reuse it too by just microwaving it again. So that's a improvement over silicone. The worm fishing lures are quite durable. It comes in clear and you add pigment. I plan to add acrylic paint and may switch to dies or lacquer paints to see what works. I think using this as skin is being slept on. It seems like it could have huge potential. You can shoot it into a mold or apply it over a 3d model by spray or brush or knife application methods. Then peel off and use. I love that it can cure instantly in theory if you spray the hot surface of it with upside down compressed duster can - this is how I get hot glue to insta cure. A instant cure is amazing for fast results. I like super glue/401 glue because it insta cures with accelerator spray. Anything with no wait time for curing speeds up workflow and enables me to move quicker in getting steps done. This would make it superior to silicone due to no wait times. A power mesh backing fabric will give it the rip resistance it needs just like silicone mask makers use.
-
I had a eureka moment recently that I wanted to share. So basically I was thinking that I may not need to read back emf from a BLDC motor in my custom motor controller. Instead, I can have it just mindlessly advance the motor at a fairly low power mode by default and a default speed of advancement of the rotating electromagnetic field. Without feedback, it may overshoot, rotating faster than the output shaft and thereby skipping some turns. That is the reason why people want to read the back emf to avoid that issue and instead only advance the electromagnetic field forward at just the right moment - the zero point crossing moment. But I was thinking about it and realized that is not really necessary. For this application, if skips start happening, it doesn't really matter. To the degree that skips are happening, the motor will stop advancing the load with its winch system and this will show up when readings are taken by the potentiometer measuring the final joint angle. If alot of skips were taking place, the advancement of the potentiometer would not match the angle it thought it would be at were no skips involved and this would tell the motor controller that it has been having skips and give it an idea of how many skips as well based on the divergence of projected joint angle by now and actual joint angle by now. So then it would turn down the speed a bit or turn up the amount of on time of its pwm and thereby put more force into the rotating magnetic field to give a bit more oomph to the motor. It would then track progress by way of the potentiometer again and see if that solved it. If it still is skipping a fair amount that could indicate the load is more than expected or there is a jam in the system or it just needs more power and it could turn up the power more and slow the speed down more on its rotating magnetic field overall speed and try again. Rinse and repeat until it finds the sweet spot or finds out it simply cannot lift the load because its too heavy or there's a jam in the pulleys or w/e. So in a way then this would give it collision detection as well as the ability to have an idea of how heavy loads are based on how much it had to slow down and add forces to get the joint to move. I then see no real need to implement ANY back emf reading NOR any need for hall effect sensors etc to monitor rotation progress. The potentiometer on the final joint the motor is actuating is enough clues to tweak the rotating magnetic field to our satisfaction. By eliminating the back emf circuitry we greatly simplify the schematic of the motor controller, suffer negligible performance hit, and eliminate a lot of processing for the microcontroller chip handling the logic of many bldc motors simultaneously which means it can handle more bldc motors by itself. It doesn't get bogged down so much by having to read in all the zero point crossings as part of its routine. This saves on processing demands and processing speed demands. Getting this all to work in real time and perfecting it will require a fair bit of trial and error but this is how I'm seeing it working out and my proposed solution for simplifying things. I think it should work great! I'm excited to have much more dumbed down circuitry like this and to get to working on this soon. Just have to finish making my pulleys and then this electronics development can get underway again. That's why I've been thinking ahead about it a fair bit since it seems I'm likely nearing the end of solving the pulleys situation soon.
-
Here's just a couple of my latest design drawings for my archimedes pulley system and a double stacked pulley setup.
(https://dollforum.com/forum/download/file.php?id=1424324&t=1)
And here are assorted parts progress for the archimedes pulley system:
(https://dollforum.com/forum/download/file.php?id=1424332&t=1)
-
A couple discoveries were made today.
#1- I noticed it was about impossible to pull from the bottom of the Archimedes pulley system and get the motor to unwind. After discussing the issue and potential causes with chatgpt for a while we figured out that the culprit is the tensioned string I put onto the output shaft of the motor to allow for snug unwinding and winding of the opposing string pair that I installed for manual turning of the motor shaft during testing. This tensioned string wrapped around the motor shaft only requires about 1lb of force to pull the motor enough to turn the motor output shaft. However, after the downgearing, to fight past that 1lb resistance to turning the motor output shaft would require 12lb of force since you have to divide the force applied at the output end by the number of downgear ratio you are at! And so after all points of friction in the pulleys and teflon tubing and the motor output shaft's magnetic cogging even while freewheeling we might be more like at 13-14lb of force required. And that is a TON of force to apply by just hand gripping fishing line. So I figured my system was just way too resistive somewhere or collectively and completely non-viable until we solved this issue! The 1lb at the motor might not seem big but it's HUGE to overcome when pulling from the backside after all downgearing. Wow. So we solved that big scare. I was very concerned and exploring alternative plans thinking we might have failed with pulleys approach before this was finally solved today. I'm so relieved. So once we remove those strings which are impeding the motor shaft from turning, we should only need a reasonable say 3lb of force on the back end of the pulley system, exerted by springs, to get the motor to unreel for joint extension back to default stance.
#2 - While exploring the aforementioned issues with trying to unwind the pulley system from the downgeared end, I began to realize the tension spring on the far side that unreels the motor and unwinds the pulley system has to be significant. I was exploring my options when an idea hit me: what if I used straight wires lashed onto the finger like a splint on the finger joint. I could put several fine spring steel straight wires parallel to eachother say .3mm in diameter wires and have them distributed as needed around the finger parallel to the finger. Then when the motor is done actively reeling in the finger to get the finger to flex, these resistive wires will be placing significant force to straighten the finger back out because they want to return to their straight state ASAP. By doing the return spring in this manner I save a TON of space since I'm putting it snugly around the joint itself and then don't have to put tension wires (a ton of them) into the forearm somewhere or w/e. I'm using space hugging so tightly to the finger that its space that seems unuseful until this idea came to me! So I pretty much deleted the volume taken by all the otherwise necessary tension spring wires if this idea works! I bought a large assortment of 40cm length spring steel wire off amazon to experiment and try out my idea. This could be epic! As a side benefit, these can act as additional support for the joint itself preventing sprains and dislocations of the bones and keeping everything snug and compact in a way that really helps support and aid the artificial ligaments I already have in place.
(https://dollforum.com/forum/download/file.php?id=1427501)
-
Here's my completed V2 archimedes pulley system finally done! It is 16:1 downgearing and this pairs with my 2.77:1 downgearing on the turn in place pulley on the motor for a total of 44:1 downgearing. It is fully rigged then from motor to finger and ready to go into testing soon.
(https://dollforum.com/forum/download/file.php?id=1429939&t=1)
I just need to do a couple reinforcements here and there on some stuff but overall we are more or less ready to move onto setting up the return springs that my last post mentioned. So that is next. Then electronics to actuate it and test it finally! Exciting times!
Also, I have come to the realization that these straight spring wires may be perfect for forming the exoskeleton mesh shapes that create the framework scaffolding over which the artificial silicone skin will overlay. The fact it has memory and wants to return to its prior shape after impacts is perfect for this application. I'd be simply forming a grid in the shape of the muscles over the bones using this stuff and then onto this grid I would overlay the silicone skin suit. The grid can be configured to even move under the skin emulating muscle contractions to simulate real muscles moving under the skin in terms of its appearance during movement. I was originally leaning toward zip ties to make this part or nylon 3d printer filament but this spring wire may be even better due to being strong, resistive to breaking even more durability wise, holding its shape perhaps a bit better, etc. The other options I mentioned aren't bad but I just think I might like working with spring wire a bit more intuitively. We'll see.
-
Well the straight spring wire acting as a finger joint spring idea was a bust. Turned out when it bent to 90 degrees it would not return to straight again. I thought spring wire would but this stuff didn't. This is not what chatgpt said would happen so chatgpt failed me this time. Anyways, still glad for its help when its right which is most of the time I think.
(https://dollforum.com/forum/download/file.php?id=1432857&t=1&sid=0baa2b04465232dd3cd2d8cd63fa5bfe)
(https://dollforum.com/forum/download/file.php?id=1432860&t=1&sid=0baa2b04465232dd3cd2d8cd63fa5bfe)
That said, I fell back to my original spring solution which was to use a 3mm diameter tension spring as the return spring. I experimented with different lengths till I got one as short as possible that would stretch out the necessary .75" roughly to accomodate the finger joint's reverse direction counter tension needs. The shorter the spring the more it resists being pulled and also the thicker the spring the more it resists being pulled. I used default thickness from my premade tension spring order and it seemed fine and the length of the spring I cut and tested trial and error till I found a good length for my need. For my .75" draw length I went with one 1cm long spring which stretches itself out to .75" + 1cm in total without ruining itself. It seems like it pulls around 2lb of pulling force but I haven't measured it with a scale. I fed it through bowden tubing from the place I mounted it on the motor all the way to the joint being actuated - the backside of the index finger. It's job is to keep the archimedes pulley system and winch in place pulley taught at all times and to return the finger to full extension when the motor is not actively pulling it into a grasp position. I have not yet tested if it is strong enough to do this job but assume I'll need two of them to be strong enough. I'll test with just one for now and add another spring to double it's strength if needed later.
I deliberated alot on where to mount this spring and last minute decided to just mount it on the motor it is counter tensioning since I have enough space for it there and I can just follow the same bowden tube routing the motor is using generally. This seemed easiest for me given my massive space constraints and the need for a ton of these springs to handle all the finger joints. Seems like it should work well so far.
-
Ok so a few minor updates:
I have decided that since I am employing tension springs to actively work against the motors in a constant tug-of-war while the motors try to grasp, I'm losing grip strength based on that. To make up for that, I'm going to use a separate motor for the distal-most fingertip joint and the second to distal-most fingertip joint rather than have a single motor do both of these joints. I made these adjustments in my CAD. I will have to change the tubing setup for the grasping tubing of the index finger to reflect this change too. This will also give the fingers even more precision and dexterity in the end - not to mention a massive boost in strength - so it's well worth it.
I also decided to use n20 gear motors for the axial rotation of the base of the fingers instead of BLDC motors like everything else since these will only be used when doing the tiniest of micro adjustments and rarely employed - so a little gear noise once in a blue moon for this precision work on a tiny scale should not be that bad. So that's 4 N20 gearmotors going in. These are being used just to save on space taken and pulleys needed a bit. I'm putting these 4 into the forearm in location pictured.
(https://dollforum.com/forum/download/file.php?id=1437072)
Next, when the spring is pulling, I noticed the TPFE guidance tubing goes from straight and relaxed to wavy under the tension. It is trying to compress under the friction which is what causes this. In the worst cases, Will Cogley's robot hand project had this same issue and the tubing literally compacted so much near the ends that it developed wrinkles/folds where it was crushing the tubing and destroying itself under the pressure. Mine is not to that extreme but this is WHY people put metal coils around the tubing for bike brakes to prevent crushing forces onto the tubing. I don't think I will need this but I might put it in certain places as a last ditch effort if needed later. That said, to prevent some of this compaction stuff on the spring's tubing, I'm going to be using TWO tubes which will divide up these forces causing this by 2. Sharing the load between them evenly. So the tension spring will have two fishing lines coming off of it and two tubes to guide that line to the finger joint where it does it's thing.
-
Disaster has struck:
In testing recently, I had some VERY bad news: I don't think the spring extension idea is going to work. The amount of force required to unravel the Archimedes pulley system when working against all the friction in that system, the friction in the winch in place pulley, all the friction in the teflon tubing runs, and the magnetic friction of the motor itself while working against the downgearing (since when working in reverse direction it acts as up-gearing) is all working against the spring and I think it's too much to ask of that spring. I can't even really pull by hand - pulling pretty hard like 3-4lb of force it wasn't budging. So this is tragic for my whole approach so far and we have to go back to the drawing board. A proposed massive overhaul solution in next post.
Note: The name of the resistance to turning a BLDC motor has while freewheeling (no electric applied to it presently) is called cogging torque, which is caused by the interaction between the permanent magnets and the stator's iron core. This force may seem insignificant but due to my downgearing system, the spring has to deal with it after it has been multiplied 44 times due to the downgearing the spring would be fighting through from reverse direction at the bottom of the pulleys and traveling through what then acts as upgearing when going in reverse direction from spring's end.
-
I think I've solved it! So first, I want real force working on the extension aspect, not some wimpy spring. I already said there's a lot of frictions that extension system has to bust through to work. And I'd hate to have a very strong spring anyways since when grasping, the motor would then be fighting against a strong spring for extension which is a huge inefficiency that works to weaken the grasping action significantly at that point which is bad design frankly. So we want IN DEMAND opposition for the extension rather than a constant opposition of a spring fighting against the grasp attempt of the motor. We also want the motor that does the grasping to actively rotate in reverse direction rather than freewheeling in order to not have to fight it's static friction caused by its magnets which is significant. This means we either have to go with a two motor system - one for grasp direction of the joint and one for extension direction of the same joint (HORRIBLE WORST CASE SCENARIO BUT POSSIBLE IN A PINCH) or we need to go BACK and refute the notion that the motor is unable to operate two separate pulley systems for extension and grasping functions coming from a single motor attached to two pulley downgearing systems. Which would entail the motor turning clockwise to create grasping and counter clockwise to create extension. The problem with such a proposed system is that in theory it was said to be impossible due to the inevitable derailment issues and tension issues that this would invite. I am proposing we tackle those issues it invites head on rather than avoiding them entirely like we were trying to do for quite a while now. It is a VERY tall order to get that to work but that would be the best possible scenario IMO. It is great if we can get it to work since we tap into the full power of a single motor to do both flexion and extension and we then kill two birds with one stone. All the friction issues with the tubing and pulleys is solved by the motor when it reverses directions and actuates the opposing pulley system. We just have to have slack in the line due to the different diameter mismatches of the two different winding directions we face and also have to have that slack pulled taught by some mechanism to prevent slop that causes derailments. I really want to press for that HARD now. But to do that I really have to scrap the winch in place pulley idea basically I think. Well not necessarily - even that I think can be worked out but is higher risk and harder than my current favorite new, novel solution. So we can reattempt winch in place stuff perhaps in the future but I want to set it aside for now. My newest idea is for that first large run-out downgear to be 2:1 and use regular Archimedes pulley system approach but to put that pulley into the torso and have a weight hang off the bottom of it or have a VERY tiny motor attach to the bottom of it that is to place tension onto it regularly to remove all slop. This can be a motor the size of my pinky fingernail perhaps (not sure though). OR a weight. I lean toward using a weight now since that would be easiest I think to pull off. I got the weight idea from studying the cable machine for triceps at the gym the other day. I can have the same type of weights or something similar to those used by gyms. But doesn't have to be adjustable like those but same concept.
Granted one downside to this approach is what if the robot is laying down or upside down wouldn't it not have weight able to pull down by gravity then? So to solve this I can have 3 weights perhaps, one for each possible direction: upright robot, upside down robot, laying down robot... actually 2 weights should be fine: laying down and upright. Hmm... well if he's laying on back or stomach the weight would have to pendulum or slide past a central point to the other side of robot on a track. Yeah that should work! So 2 weights I think can do it. If upside down he's screwed we'll say. He won't use fingers in any direction change way until he flips back around upright or sideways if doing a cartwheel or handstand for a bit. That is a fine tradeoff. Right now I'm thinking a straw with lead tube in it as the weight or something like that. Even considering just using a fishing sinker perhaps at the moment. Have to think on this more...
-
Here's the official design drawing of this proposed single motor actuating both forward and reverse directions with two separate Archimedes pulley systems opposing one another. You'll also note that the left hand side of the drawing has a pair of Archimedes 2:1 pulley downgear systems, one for forward and one for reverse directions of motor and these two are going to be very long (16 inches long) and therefore are located in torso. The remaining 16:1 Archimedes pulley downgearing systems will be kept in the forearms near to the finger joints they are actuating as we had planned originally and already have in place.
(https://dollforum.com/forum/download/file.php?id=1441428&t=1)
You'll also note the weight that hangs off the bottom of both of the 16" long 2:1 pulley downgear systems that can keep them both taught at all times despite their varying lengths that will always be changing. The weight is able to slide since it has a fishing hook eye above it and on both attachment points to the 2:1 pulley downgear systems so it is always adjusting these 3 fishing hook eyes to always keep tension on both systems freely.
-
Also, I recently stumbled upon a VERY much simplified version of my miniature pulleys. So up to now I've been using 1x3x1mm ball bearings to make tiny pulleys and been variously perfecting this approach but it is still not THAT small and is a bit complex to make and we have to make literally THOUSANDS of these to do the whole robot. That presents a bit of an issue due to the large work that requires. At least until mass manufacture of them comes in one day perhaps. But while DIYing that, it's alot to deal with making SO MANY somewhat challenging to make things. That said, my proposed EVEN MORE miniature and WAY WAY WAY simplified to make pulley is to just use a single fishing hook eye. Literally, that's it. I can use a tiny fishing hook eye and use that as my very first pulley for the 2:1 16" long Archimedes downgearing systems in the torso. This will cut down on size taken dramatically and complexity of its build. It will make the pulley basically failure proof too. The way it will EVENTUALLY fail is by the rope rubbing it enough to cut it in half. But I think the rope would fail before the pulley would fail and so that doesn't matter then. You'd replace them both at once on routine maintenance. No need then to worry about that eventuality. And the ridiculous ease of manufacture of such a simple pulley makes replacing it trivial. I also think that using this just in low load, high speed, low force early pulley downgearing stages is a non-issue since the friction with such a low load on the first downgear or two will be so trivial that the string itself would fail WAY before it would slice through the metal (acting like a saw over time). I think it would take literally MANY years due to the super low friction at these low forces. Now I'll still use the ball bearing style for later stages of downgearing where the loads go way up, but for the first stage or two I think this will work just fine.
(https://dollforum.com/forum/download/file.php?id=1441427&t=1)
-
So the idea to move a portion of the pulley system stuff over to the torso is now out because I've been kind of talked out of it so I'm putting that aside for now. Going to actually try to do that stuff within the forearm. Also instead of a fishing sinker I'm going to try to use an elastic cord made for making bracelets for kids. I think that will be enough force just to keep tension on the line that is being unreeled. Doesn't have to be much I don't think.
I'm also considering just hand testing my pulley systems for now. So disconnecting them from the motor shaft entirely so I can just do testing to see how things feel and can observe things easier way quicker and with less hassle. And when I do go to test by way of motor, I'm just going to use a brushed motor and connect a lab power supply by hand with alligator clips so I can avoid messing around with microcontrollers and firmware and custom motor controllers entirely which is a bunch of rabbit holes I want to avoid as I just secure testing my pulley designs for now. I don't want to get hung up in a year or two of electronics stuff just so I can test my pulleys which would be so stupid and annoying. I need to get my testing iterations done as soon as possible without distractions and longer delays. Once I am happy with the pulley's performance and they pass all my tests and everything seems solid then we'll go ahead and connect it back up to the BLDC motor and then will worry about the custom microcontroller and custom motor controller and all the firmware or whatever at that time and will be doing that with the confidence of a big win with the pulley systems giving us momentum as we enter into those rabbit holes of electronics.
-
Ok so a quick couple updates.
First, since the ideas for downgearing with pulleys have been coming in fast and furious, ways to do it easier or ways to fit it here or there or what have you, it's getting a bit scattered and I'm now starting to tear down my work too much for my comfort. It's like I'm chasing the next shiny new approach a bit overly now. So I decided to stick to the current approach as long as it is viable enough to be "good enough" so as to not waste my hard work anymore as I was starting to do. For example, the pulley system I was testing with a 10lb dumbbell did not need to be torn down and rebuilt I don't think. Stuff like that is starting to cripple progress in some sense. So my new approach is when I come up with a idea for a possibly better downgear implementation, I will just write it down and put it in a queue. Then on the next joint actuation I will use these. This way I can have like 10 different downgearing approaches over 10 joints and I can compare and contrast them, note the pros and cons of each, and over long term testing I can find the clear winners. This will also give me a greater understanding and experience and take more out of so much guesswork and into more concrete and tested territory on this stuff.
A side benefit is that people tend to think I've progressed zero with pulleys since I keep building them then taking them apart and starting over. At least under this new approach, I get joints done and over with and working before building the next downgear iteration so the progress feels more tangible and the robot gets done rather than just being in iteration and tear-down cycle hell where it appears from the outside like I am not actually accomplishing anything. So that part will be nice.
Another cool development is that I realized I can put a pulley downgear inside a tube. Normally up to now I was exiting the guide tubing to do a downgear and then afterward the string goes back into tubing to go to wherever. But I realized particularly if doing a fishing hook eye downgear that the entire downgear phase of that can fit into a tiny tube and that has some nice perks. For example, if the 2:1 downgear is the first downgear right off the motor, and the motor is reeling in 32" of string, that 2:1 will be 16" long. Well now that I can do my first 2:1 downgear all within tubes, I can run the downgear from the shoulder to the wrist, giving me PLENTY of room to deal with that amount of runout. This is quite exciting and just gives me more freedom and flexibility. I might do something with this for the first couple downgears so a 2:1 downgear pulley #1 and a 4:1 downgear pulley #2 but then do the rest in the forearm as initially planned and most likely using ball bearing based pulleys for the more heavily downgeared higher force phases of the downgearing process.
That all said, I have the downgear system of 44:1 downgear now done and attached to the finger fully and the extension spring attached to the extension side of that joint fully. So I am ready to begin testing and see how much that spring fails to extend the joint due to friction and motor magnetic cogging issues. I will then add more and more springs until it works. That is my solution. Yes, those springs collectively are fighting the motor when the motor goes to actuate grasping, however, that is just a concession we have to make with this design. Other downgearing designs that don't involve springs for that aspect but involve bidirectional motor actuation with pulley systems for either motor direction are coming next. But I'm finishing the spring based design I was talking about for some time now rather than scrapping it as I was planning of late. It is not THAT bad and it deserves to be at least tested and shown the light of day. It would be a shame to waste that work. It was good work. Also, I realize it MIGHT be the best solution. My theory says no but I can be wrong. Testing is the only way to know 100%. So it's worth keeping it as one of the downgearing methods I'll be testing out.
-
Ok so I did a big refactor of my pulleys and ran a test again and it still is not working. The first set of archimedes pulleys tops out and can't move anymore while the finger still hasn't moved. This is because of slack in the lines. I did not calculate slack in the lines into my calculations at all and am shocked by how much there is... Rather than do a major new overhaul with new math and new draw distances on every pulley AGAIN, I'm going to just drop the final pulley of the system so instead of 44:1 it will be 22:1 now. While we cut half the grip strength with this move, this might be okay after all. It still gives us 20lb of of burst grip strength I believe and 11lb of casual easy sustainable grip strength. Most common tasks should only require 8lb of grip strength anyways for a single joint tops. Because remember, I'm not doing a single motor for all 3 finger joints but one motor per joint which helps alot in the strength department and control department. So anyways, this hack I think is okay also because it hit me lately that I highly doubt I'd use the full beast mode burst strength of a 44:1 downgear anyways. I'd be too worried about the wear and tear on the fishing lines and pulleys and maintenance times getting too short between maintenance overhauls if the robot is using that level of grip strength for tasks. In reality, I am now imagining I will only let the robot do VERY minimal strength stuff to reduce the maintenance to a minimum. Like sewing, cutting, and delicately picking up small loads. I will treat it like it has the strength of my 4 year old just to baby it and make it last longer between repairs. Kind of like having a old beater car you don't trust and never throttling the engine hard but just gradually easing on the gas pedal to avoid blowing a gasket so to speak and avoid a trip to the mechanic. So that said I think 22:1 might actually be okay. And with that final pulley out of the way, I'll have WAY more than enough draw distance to bend the finger 90 degrees and account for string slack AND account for string stretch over time without any issues at all. Much better. Not to mention we do pick up speed this way and that might be a VERY nice feature when all is said and done. A faster moving finger can speed up its work I think. Like notice how 3d printers go way faster and that speeds up prints. So speed might be king over grip strength in the end perhaps. It's a tradeoff.
Another update is I realized I can wind a second very fine 0.08mm fishing line on the output portion of the winch in place pulley mounted next to the motor and this second line coming off that pulley will be attached to a tension spring consisting of a bracelet jewelery making cord for jewelry for kids. This line will maintain tension on that winch in place pulley and the motor output shaft at all times to prevent derailments. The metal tension spring that extends the finger will then have the help it needs to keep the whole system taught. That's the plan anyways. The runout of this line will need to be 12.48" of tensioned draw. To achieve that I need a length of this cord of about 15" I think which stretches to 27.48" at full extension. This would occur each time the motor causes the grasping actuation and it would be playing tug of war with the motor so that when motor relaxes or reverses direction, the winch in place is remaining tautly in opposition.
-
A note on fishing line durability. I think this was mentioned in passing quite a few times but at some point, a mention of durability concerns becomes that final mention that makes you really start to question it more and so I finally did some research on chatgpt and found out a human finger joint probably will actuate like 1-2k times per day which blew my mind since that would add up to like 10-30k times per month and so basically, once a month the main finger fishing lines will likely need replacement. I looked into alternative materials but didn't have much luck. So what to do?
Well after thinking about this a fair bit, my conclusion is to just shrug and move forward as it stands with the fishing line approach. I'll treat them as a consumable. My plan now is to just expect 1 hour of maintenance for every 20 hours of runtime. Or maybe to be more conservative, lets bump that to 1 hour of maintenance to every 10 hours of runtime? Maintenance will involve redoing pulley systems with fresh fishing line, or swapping in full new pulley systems to replace older ones every so often. It can have a pre-emptive maintenance schedule. My intention is that one robot will maintain his neighbor and the two will have a buddy system of maintaining eachother. Once I have expected time to failure of fishing lines established, they can swap in new ones automatically to prevent failures from happening during work times.
I don't think this is too bad of a deal or a deal breaker. Yes, hopefully materials advances will give me a better string one day, but for now, I'm okay with this maintenance scheduling thing. As long as its all automated, I think this is fine.
After all, our bodies muscles constantly need repairs and they grow from the repair process. So what do you expect for artificial muscles that can't self heal? Maintenance has to be a regular thing IMO.
-
Update: I bought several sizes of kevlar string to use to replace the PE fishing line particularly in the high tension areas that may face the highest durability challenges. I found it on amazon in many sizes. I just bought one of each size: 0.5mm diameter 50lb test, 0.8mm diameter 100lb test, 1.1mm diameter 200lb test and 1.3mm diameter 300lb test. This is probably a game changer for my project IMO.
-
After further consideration, I'm scrapping using the elastic cord for a bracelet idea (as a tension spring for the winch in place pulley). The point of that was to use as little space as possible but I just don't trust it. I am not sure what material it is made of and my experience with rubber bands has always been dry rot issues. I am going with 2mm OD tension spring instead. It has to stretch 12.5" and so I'm using a 12.7" strip of it to start. That feels like a snug stretch but does comfortably reach the 12.5" of stretch needed. This brings its stretched total length to 25.2". I bought 3mm ID 4mm OD TPFE tubing to be its guidance tube for this. That arrives tomorrow and then I can begin assembly.
This 4mm OD guidance tube is a bit bulky and long for the arm IMO so I will relocate it to the torso since if I use this method for other motors these 4mm OD tubes will add up in space taken up fast. The arm can't house them - it's just too much space taken at that point for these. But the torso can house them in the back or sides I think. For now, since the torso is not yet attached, I'm going to place this tube ON the string suspended from my ceiling and treat that string as though it were to torso for now.
-
Here is the tension spring in question from the previous post. I want this spring inside the tubing though which is not shown in the drawing of it.
(https://dollforum.com/forum/download/file.php?id=1473959&t=1)
-
Good news: I had mentioned before I was planning to use 2mm OD tension spring for the winch in place pulley tension solution but once I got the 3mm ID 4mm OD PTFE tubing to go over the spring, I saw that the 4mm was just WAY too big once you multiply that out to 300 motors. 300 of 4mm OD tubing starts to take up a massive area at that point and I struggled with that. I MUST be miserly on space taken up by parts to get all the crap I need to fit in there to fit in there! Anyways, I fortunately discovered that you can buy tension spring down to 1mm in OD! I was unaware of this before now! You can find it if you search "0.2x1.5x1000mm tension spring" where 0.2mm is wire thickness, 1.5mm is OD, 1000mm is length. So I ordered 1mm OD tension spring and 1.5mm OD tension spring to test and see what seems best. If the 1mm OD spring seems reliable to me, I'll go with it. Anyways, since the spring is now smaller, I can use also a smaller PTFE tubing to house the spring so I ordered uxcell PTFE Tubing 1.8mm ID x 2.2mm OD off amazon. 2.2mm OD tubing compared to 4mm tubing is SHOCKINGLY smaller when you look at them. So it will be WAY more space efficient now.
Here's my updated tension spring concept drawing:
(https://dollforum.com/forum/download/file.php?id=1477723&t=1)
-
Ok so I currently have an order for 0.2x1x1000mm tension springs stuck in customs for weeks and placed another order just today for the same in hopes it goes through faster. But at $9 for a single spring that is 3ft long, I am feeling RIPPED OFF on price. It is bullcrap. All relating to the tariff nonsense. So I decided today to pivot and just roll with the elastic band in place of tension spring. It's a jewelry making elastic band I bought some time ago in a roll. WAY cheaper at $0.03 for 3ft instead of $9 for 3ft. That's 99.7% off! Talk about a discount! The issue I had before when I looked into this option was the tie-off point. I would need a way to tie PE fishing line to the end of the elastic band without the tie point being bulky. Well I figured out a way to do it without any bulk at all! See I want this to fit into my 1.8mm ID PTFE tubing to keep size down. My solution was to just glue the fishing line lengthwise directly to the elastic band. No knot at all. No turns at all. Just literally lay it on top and glue it down flush. I figured about 6mm length of joint would be solid. And I did this on both sides with my PE fishing line. I used 0.08mm 6lb test braided PE fishing line for this. So now I have two fishing line segments coming off the end of it for double the strength of this connection. But I only wanted one piece of fishing line to go the distance to attach to the motor end so I twisted the pair of fishing line segments together and glued the twisted pair with 401 glue then cut one of the two away leaving just one of the pair to go the distance to the winch in place pulley that this is all supposed to tension for me.
(https://dollforum.com/forum/download/file.php?id=1485386&t=1)
(https://dollforum.com/forum/download/file.php?id=1485385&t=1)
I will use this string and elastic band method for now as I wait on springs and stick with this method for at least this first motor actuator setup for now. If the elastic bands don't last, we'll upgrade to the metal springs later on during maintenance or w/e.
Note: the total length of the elastic band I am using for this is 2ft and it stretches to 3ft snugly without too much force. I'm just going by feel and instinct for this measurement. If I were to go 1ft with 1ft of stretch, the stretch is more intense and the pull is harder. But I don't think I need much pull for just tensioning the winch in place pulley and I also think the more tension you place the more wear and tear on the elastic band which will shorten its lifespan. So playing it conservatively with the 2ft length selection for now.
Note: to apply the 401 glue I used an exacto knife handle with a sewing needle in place of the xacto knife blade and the tip of the sewing needle acts as my precision glue applicator.
-
Sometimes to get the braided PE fishing line threaded through the fine PTFE tubing can be tricky, so I came up with a neat device to assist in this. I will be making a threading tool based on a needle threader tool I've been using. It's basically a wire folded in half that you shove through a needle eye and then stick your string into its end and then pull it back through the needle eye. In my use case, I'm creating a custom one of these threading tools that will feed through my entire length of tubing till its folded end comes out the other side and I can thread my string through that end and then draw it back, bringing the string through the tubing with it.
(https://dollforum.com/forum/download/file.php?id=1497343&t=1)
(https://dollforum.com/forum/download/file.php?id=1497344)
I just ordered some 40ga copper and stainless steel wire to use to make this device in question. I'll see which metal is best. Gonna try the copper first I think.
-
Minor update: I have now carefully mounted the PTFE tubing that leads to the elastic string tensioner for the winch in place pulley. I mounted it snugly to the side of the PTFE tubing coming off the same winch in place pulley that leads to the Archimedes pulley system. I routed both of these using my CAD for reference in such a way that their routing will not interfere with the next motors that will be installed later. I mounted this PTFE tubing that leads to the elastic string tensioner using ONLY 401 glue which is something I've never tried before now. Usually I first wrap the tubing in adhesive transfer tape and spandex cloth wrap and coat the cloth in 401 glue but skipping that made it able to be more snugly mounted to the other tube by way of only glue. We'll see how that holds up without the other reinforcement the cloth provides etc. Seems to look so far so good though. They are in turn glued to paper soaked with 401 glue and to a little piece of stainless steel wire bent at a 90 and that wire in turn glued to the winch in place pulley mount baseplate which is itself made of paper and 401 glue. So basically everything is becoming 401 glue construction! I have some concerns about how this will hold up in the event of a fall or w/e but perhaps we can create some sort of protective cage around any delicate outcroppings like this in the future. For now I am just going for ease of construction and speed of construction to get things back on track and rolling again.
(https://dollforum.com/forum/download/file.php?id=1518028&t=1)
Note: The PTFE tubing that leads to the elastic string tensioner for the winch in place pulley is 0.66mm ID 1.16mm OD PTFE teflon tubing. The string coming off the winch in place pulley feeding into this tubing that will act as tensioner string tension carrier string is 6lb test 0.08mm PE braided fishing line. I was able to thread this fishing line into this TPFE tubing by hand with no issues at all very easily.
The next task will be to mount the end of this string to the 2 feet of elastic string for jewelry making and thread that into 1.8mm ID 2.2mm OD PTFE tubing and tie it off at the end of that tubing and then mount that tubing to the gray string hanging from my ceiling for now. That will conclude the tensioner mechanism for the winch in place pulley and this will usher in the next round of manual hand testing to see how much tension that is giving us. I also will be moving the tension spring mounted on the motor to align it better and shorten it more since it only moves like 4mm and so can be way shorter than it is now.
-
I finally finished making the tensioner mechanism for the winch in place pulley and I taped it off up the string descending from the ceiling and taped the far end of it onto the ceiling. I noticed I have to keep it as straight as possible since when curling with too much turning the elastic bracelet cord grips the sides of the PTFE tubing which could interfere with the amount of tension it brings to my winch in place pulley. So this will mean on the robot itself it will have to go from the shoulder all the way down the torso in a straight line and then down the leg to about the knee as well. It's 44" long in total. I ended up bumping up the elastic bracelet cord to 30" long to reduce the amount of tension it puts on the winch in place pulley more. The longer it is the less tension it brings and the shorter it is the more tension it brings. If it really can't fit into the leg I can cut the elastic bracelet cord in half and place braided PE fishing line in between the two halves and have that make a 180 degree turn around a pulley and thereby have the same length of elastic bracelet cord but separated into two halves mounted parallel to eachother that create a in series matching tension but taking up half the overall length. This way I could keep it out of the leg area if needed. However I think it might fit into the leg area fine perhaps. Not sure (once we get all the other motors and their tension strings that amount of 2.2mm OD PTFE tubing will start to add up.
(https://dollforum.com/forum/download/file.php?id=1519262&t=1)
Note: I'm also considering taking the elastic bracelet cord out of the tubing and lubing it then putting it back in since lube on the grippy elastic bracelet cord would take away it gripping the sides of the PTFE tubing some I think. Silicone lube is best for this according to chat gpt.
Note: to secure the far end of the elastic bracelet cord I used 401 glue to glue on PE fishing line onto its end the same way as we discussed before and then took the far end of this PE fishing line and came out the end of the PTFE tube with it and taped it off onto the outside of the tube. We'll see how that holds up it might need to be glued down if it gradually is pulled through the tape over time which would be no good.
-
The tension spring mounted to the motor setup upon further testing seems like a somewhat bad method. The issue I'm having is too much play in the tubing running between that spring and the finger joint. When tension is applied to that spring by way of the tubing, the tubing recoils and moves quite alot and allows alot of slack out to the joint so that the spring has very little involvement in the joint and doesn't really get used much period. So the full range of motion of the joint is just absorbed by tubing slack. When I tried to pretension the tubing so that the joint movement translates to the spring, the total tension placed on the joint by this became too high.
Fortunately, I came up with a much more elegant and simple solution for all of this. Basically, my plan now is to just use the bracelet cord tied point to point across the joint directly on the joint and that will be my spring for extension that counters the motor. This eliminates the need for metal springs at all which cuts costs, it also eliminates the PTFE tubing run, saving some space, and should be easier to install and easier to give precise amount of elasticity/resistance to taste. If I want more springback on the joint I can just add more bracelet cord in parallel to the first. This way I can add more resistance pretty easily.
(https://dollforum.com/forum/download/file.php?id=1524992&t=1)
-
So in recent testing a fresh issue I ran into was the TPFE tubing would start gradually pulling through its tightly wrapped tape sleeve to my surprise. Its low friction surface gradually pulls free of the tape over time. To resolve this, I decided to thread through the tip of the tubing to create a mechanical bond for the tip and once threaded through I just 401 glued down the ends of each thread onto the sleeve that was originally supposed to hold it in place to begin with. This seems to work great so far in the little bit of testing I've done since.
(https://dollforum.com/forum/download/file.php?id=1525454&t=1)
(https://dollforum.com/forum/download/file.php?id=1525455&t=1)
-
I figured out a robust way to make the extension cord for finger extension using the bracelet cord and a fishing crimp sleeve. The idea is to crimp the two ends of a folded in half strip of bracelet cord and this way both ends can be sewn down into the fabric without any gluing which could potentially fail or be a weak point. I am planning to use this in place of the tension spring style finger extension setup.
(https://dollforum.com/forum/download/file.php?id=1534924&t=1)
-
Ok I figured out a bit easier way: tie a knot at each end of the strip of bracelet cord and then tie my nylon thread off onto the bracelet cord inside that bracelet cord knot. The bracelet cord knot on each end acts as an endstop. Seems to work great so far and cuts down on materials this way over the previous way I proposed.
(https://dollforum.com/forum/download/file.php?id=1539287&t=1)
-
Okay so the bracelet cord self untied quickly so I'm going back to my previous approach of tying off both ends of the bracelet cord with a fishing crimp sleeve.
While trying to cut in half fishing crimp sleeves with my mini miter saw I noticed it was a difficult process and not ideal. So I came up with a easier method which was way faster, cleaner, less setup and takedown, no deburring needed, etc!
The method is to lay the fishing crimp sleeve on a flat surface and line up a exacto knife blade perpendicular to it across its top and then apply moderate downward pressure to score the metal and then slide the knife carefully back and forth creating a perfect scoring line that grows deeper with each pass. After several passes the fishing crimp sleeve halves separate cleanly! This method uses a similar principle to a copper pipe cutter used in plumbing.
(https://dollforum.com/forum/download/file.php?id=1543136&t=1)
-
I installed two tensioners for the robot and they were seriously successful overall in testing. So much so that I am now confident enough in the entire pulley system to move onto the custom mini BLDC motor controller to get the motor to run motorized tests of finger movements next. Well after a couple very minor tweaks that is.
So the first tensioner I installed on the extension part of the index finger joint we are working on. I used the bracelet cord folded in half and fishing crimp sleeved then sewn into the bone fabric. It seems just about perfect except for one thing: I want to keep it under mild constant tension but the bone fabric creeps/moves slowly when put under constant tension like this because it is taped into place on the bone after all. The tape is allowing the movement. This means it does not stay put and my anchor points move over time so I can't set a tension and rely on it staying at that tension long term. To resolve this I need a mechanical connection at the tension point anchoring location.
(https://dollforum.com/forum/download/file.php?id=1545075&t=1)
To mechanically connect my anchor point, I have decided to use tiny self tapping screws. I have avoided screwing into the bones till now but I'm making an exception here. The screws won't be going that deep and the finger bones are unlikely to break anyways IMO. So I feel comfortable with this. Here's the screws I ordered for this from Amazon:
(https://dollforum.com/forum/download/file.php?id=1545085)
Next, I created a tensioner for the middlemost archimedes pulley. That pulley was creating significant drag and slowing down the finger extension during testing due to rope friction. So adding a tensioner line to pull it back down toward the fingers during extension was my solution for this. It worked amazingly well. To make this, first I tied off a fishing hook eye to the bottom of the radius bone just above where my TPFE guide tubing entrance is. Then I glued a 7cm piece of bracelet cord to a piece of 6lb test .08mm braided pe fishing line with 401 glue. I secured the top of the bracelet cord to the top of the archimedes pulley system and then threaded the other end through the fishing hook eye and back up and to the bottom of the archimedes pulley where I tied it off. So it ties off at top, comes down to bottom, goes through the fishing eye then comes back up and connects to my pulley. It creates just enough downward pull to delete the rope drag slowing down that pulley from coming down and this enables the system to unwind and extend back to its starting point after each time I contracts/pulls upward to cause finger contraction. This means the finger extension now happens swiftly with no hangups and the whole archimedes pulley system is now under constant tension at all times which keeps things neat and prevents tangling issues pre-emptively. This rig was a massive success and took up hardly ANY space at all. I put the post it notes behind the archimedes pulley tensioner so you can see it. It's hard to see otherwise without a contrasting backdrop. It works amazingly well.
(https://dollforum.com/forum/download/file.php?id=1545087&t=1)
-
Back on the electronics again. Have been going over my BLDC motor schematic and making some little tweaks to it. Here's the updated schematic. It's a combination of lots of other schematics I've found online as well as some chatgpt help. With 1 being no clue and 10 being absolute expert tier in BLDC motor schematics I'm probably a 5 IMO. So take my design with a grain of salt. It will be very fun to see if it works. Note that I put a couple schematics of Electronoobs - a great youtuber on the left hand side as reference and study material. My schematic is the big one on the right. Electronoobs series of videos on BLDC motor controllers has been extremely helpful in me forming a rudimentary understanding of this stuff.
(https://dollforum.com/forum/download/file.php?id=1547139&t=1)
-
I started some testing on some subsections of the BLDC motor controller and ran into some problems and learned several things. I'm working with chatgpt to resolve each issue and have been updating my schematic to reflect alot of the changes I am making. One thing I learned is that for the high side switch, the voltage from gate to source has to be 10-12v higher than the drain voltage because the drain voltage becomes the same as the source voltage once the switch is on. The voltage from gate to source then either has to start out as motor input voltage + 12 while still fitting within the voltage from gate to source max allowed voltage as stated by the datasheet or it has to rise dynamically as the source voltage rises such that the voltage from gate to source is 12 more than the source voltage as the source voltage rises to become the drain voltage. Fortunately, I can have the former for this 2430 motor since I can use 6-8.4v to supply the motor and the voltage from gate to source max value is 20v. This means I can use voltage from gate to source of 20v and this, when mosfet is first switched on, does not fry mosfet but as the source rises to become 8.4v, 20v-8.4v is still 11.6v which is sufficiently high to enable the mosfet to still stay on without anything dynamic set up. If I want to go with a 12v motor supply on some of the bigger motors later on, I will need a bootstrap circuit to supply the highside mosfet with a dynamic voltage from gate to source that rises when source voltage rises. So I added that schematic diagram to this as well as an option. I also can use a mosfet driver for this but was hoping to cut that cost and added volume taken up by just using discrete components rather than a IC for this.
Anyways, to break things down even more in testing, I decided to just test turning on and off a single highside mosfet using a pair of lab power supplies, one to provide 20v and one to provide 8.4v. To turn on I connected the gate and source to my 20v lab power supply and I connected my red alligator clip of my 8.4v lab power supply to the drain and then measured from source to the black lead of the 8.4v power supply and verified 8v on that test which worked - proving the mosfet was in fact on. I then removed the black alligator clip of the 20v lab power supply from source and shorted the source to the gate to drain the internal capacitor inside the mosfet and then tested from source to the black 8.4v clip and sure enough it was near 0v so was off. But it did gradually climb back up to 8.4v after the short from gate to source was removed due to capacitive coupling and leakage according to chatgpt. So I will need to add a 10k ohm resistor between gate and source pins to short it automatically and keep it fully drained and off fully when it's supposed to be off.
So I plan to just gradually add components little by little and test after each thing is added to ensure it is working right still after each little change and this way gradually build out the circuit, proving each thing works as we go. This is because things have all these gotchas and "oh you didn't know this little detail?" that keeps coming up and proves it was more complicated than I thought. So I just have to prove every little thing as I go. To try to find out what is wrong after the whole thing is built would be WAY harder than to figure out what went wrong when a single component is added and it was working before said component was added. So that's how I will be able to overcome this challenge best I feel.
Note: Reminder: I am building a custom BLDC motor controller because an off the shelf one would not have enough miniaturization to fit into the tight space constraints I have to work with. Also, building my own gives my software more precise control of every little advancement of the rotating magnetic field and along with that I'll have the ability to PWM the advancements to make them more smooth, less noisy, and have torque control as well this way which means the fingers can be rough and fast in movement as needed or slow and gentle and dainty or slow but powerful etc. I can also create acceleration profiles that match human finger joint acceleration in order to have the movements look very natural just like a human's movements which is very important to me. Just alot of fine precision is possible when its all my own circuit I feel. While off the shelf ones may have some of this functionality, the price often reflects that and is then prohibitive. But in any case nothing is off the shelf with this level of control AND the ability to so finely tune its form factor and volume envelope to fit my exact needs in space on a per motor basis.
(https://dollforum.com/forum/download/file.php?id=1552322&t=1)
-
Well I finally got back to the electronics after about a month long detour real life interruption. All kinds of stuff slowed my progress on this session. But I got stuff done nonetheless. 0603 LED to 0805 resistor and some nickel strip leads coming off. Tested and working. This will be the indicator light for when the lowside mosfet comes on for one section of the custom BLDC motor controller. 0603 LEDs are extremely tiny for hand soldering and they don't take solder well either. I was originally going to go with blue LEDs but chatgpt said that would give off a unrealistic color through the silicone skin so orange would be better to give a more natural and less silicone skin piercing indicator light. Somehow I ran out of 470ohm resistors so I had to order more and I used my 200ohm ones instead for now. Which are a bit too bright. But chatgpt said I can diffuse the LED with a glob of silicone tinted black to darken and diffuse the light it gives off which sounds like a good idea to me. I am planning to use wire wrapping wire to come off of this assembly and tie into things. Somehow just attaching these two parts and testing it took me almost 3 hours. Between studying the schematic to refresh my memory on what is going on, visualizing placement options, overheating and destroying one LED, trying to locate the right color LEDs, shopping for replacement 470ohm resistors, researching and substituting in 200ohm resistors, discussing LED color options with chatgpt, figuring out how to solder a 0603 LED directly to a 0805 resistor part to part by hand, accidentally breaking a part off of its nickel strip lead and having to redo the connection, etc etc. All of it just crawls. Hard to stay patient with electronics sometimes and I do things in inefficient ways often. Learning what can and aught not to be done is tough from a patience perspective. But I insist on trial and error and experimentation which takes time. I just need to get into a daily habit to stick with it till completion. It's all complicated. Trying to figure out how to electronically isolate it all next. Thinking of using lamination plastic taped around it all so I can still see it all and visually troubleshoot. Also I'm considering how I can use solder wick braid as a heat pipe for each mosfet and run that over to the liquid cooling system. But it can't conduct. So thermally it can conduct but electrically it can't. Trying to figure out whether to create a barrier of micah or just thermal silicone for this and the routing needed. Also considering if I need mini coaxial shielded cable for the wiring of each or just regular wire wrapping wire when going from microcontroller to mosfets etc. Also trying to figure out if I need hall effect sensors or back emf reading or no feedback but my potentiometer and the implications of each option. Just so much to consider in all of this. And all of those considerations also slow things down even more as I have to make decisions on it all. It's quite overwhelming.
(https://dollforum.com/forum/download/file.php?id=1568875&t=1)
-
Ok so I decided to use 30 gauge wire wrapping wire and wire wrap that onto my nickel strips that I connected onto my LED setup then trim off any excess nickel strip. What I like about this is this wire is very fine so it takes up hardly any space and by being able to wrap it on I did not have to apply heat which could have desoldered my smd components by accident. I also like that it is already insulated and color coded so I don't have to worry about insulating my nickel strips the whole run to wherever this connects. To insulate the whole LED contraption here I used packing tape so I can see all my components well but still have them electrically isolated. I just folded the packing tape over the whole assembly like closing a book over a bookmark.
(https://dollforum.com/forum/download/file.php?id=1576379&t=1)
note: after wire wrapping the wire wrapping wire I noticed it was not that tight on there. I did not use a wire wrapping tool because I lost mine so I just used needle nose tweezers to manually wrap it around and around. Anyways to tighten it well I just crimped it with the tip of my wire strippers that has some kind of toothed pliers that crimps things well. After doing that the connection appears very solid.
-
Couple updates:
An audience member redid my brushless DC motor schematic in the traditional commonplace formatting which for most is easier/quicker to read and understand due to familiarity. So I'm reposting it. It looks mostly accurate although I have since added a 100nF ceramic capacitor between the gate and source of the highside mosfets to reduce ringing issues. Standard practice according to chatgpt. I also changed the LED color to orange because chatgpt said blue would show through the silicone skin more and add a cold inner glow and we want it to look like real skin so no blue.
As to why the highside mosfets get a 100nF ceramic gate capacitor but not the lowside, here was how chatgpt explained it to me:
-High-side MOSFETs:
Their source pin moves up and down with the motor phase (it?s not at a fixed potential).
During switching, the drain and source both move rapidly, and the gate voltage must track that movement precisely ? any ringing or inductive noise can momentarily over-stress Vgs.
That?s why we add the small capacitor across gate and source: it tames that high-frequency ringing and helps hold the gate steady relative to its moving source.
- Low-side MOSFETs:
Their source is solidly tied to ground, so the gate always swings relative to a fixed, quiet reference.
They don?t experience the same ?floating? gate drive or large dv/dt transitions on the source pin.
So, the gate is inherently more stable, and you don?t need that extra 100 nF G?S capacitor.
Anyways, here is the audience member schematic:
(https://dollforum.com/forum/download/file.php?id=1579683&t=1)
Here is my updated schematic with the changes I mentioned:
(https://dollforum.com/forum/download/file.php?id=1579684&t=1)
In further news, I tediously installed the new 100nF ceramic capacitor between gate and source of the mosfet. Due to the close proximity to the 10k ohm Vgs resistor and various other low temp solder joints in the immediate vicinity, any heat applied would surely have caused those to desolder and the whole thing to start falling apart so I ended up just soldering nickel strips to either side of the 100nF ceramic capacitor (by itself off to the side) and then used the tip of a sewing needle to apply a tiny amount of conductive silver glue onto the gate and source nickel strips coming off the IRLR7843PBF mosfet and then pressed the nickel strips of the ceramic capacitor into that. I put that in front of a mercury vapor bulb for an hour or so to cure and then applied another generous helping of conductive silver glue over the top of the joint. I then baked that another 7 hours under the mercury vapor bulb again. This photo shows the final result.
(https://dollforum.com/forum/download/file.php?id=1579689&mode=view)
It appears to be a solid joint and I think this is a great way to make attachments when you can't use soldering! It might even be better than soldering in some cases from a ease of application perspective but not sure yet on that.
-
Okay so here I have attached the LED and resistor pair with their 30ga wire wrapping wire onto my highside mosfet's front face. I may add conductive silver paste to the wire wraps in the future if any issues come up there. However, I am wondering if just tightly wrapping it in electrical tape would more or less guarantee the connection doesn't open circuit. We'll see.
(https://dollforum.com/forum/download/file.php?id=1581451&t=1)
I also finished soldering together six braided copper solder wick strands which will act as my heatsink for my highside mosfet. I am still deliberating on how to attach it to back of mosfet in such a way that it will be electrically isolated but thermally conductive. I am leaning toward thermal tape for this.
(https://dollforum.com/forum/download/file.php?id=1581452&t=1)
-
I just tested the positive high-side switch portion of the motor controller and everything seems to be working as intended. The section including all parts involved is circled in a bold blue line to indicate the portion I just tested successfully.
(https://dollforum.com/forum/download/file.php?id=1592858)
One issue I'm having though is that the drain of the A09T attaches to the 100ohm resistor tightly and is a weak point that broke off twice now. Hardly any wiggling at all on the arduino input line and ground line leading into the A09T mosfet causes the drain solder attachment to break off. I am wanting to glue it all down onto the mosfet but I'm supposed to tape the heatsink on under all this stuff so I don't think I should glue it down. I need some kind of backing sheet to glue things off onto (where a PCB normally does this job). Which will provide much needed strain relief at all attachment points. I guess I'm learning the hard way why PCBs are used in general. Without a flat backing plate or substrate of some sort the attachment points between components are vulnerable to flex and breakage super easily. This surprises me.
(https://dollforum.com/forum/download/file.php?id=1592861&t=1)
To perform the test I used one lab power supply set to 20v and one set to 8.07v and used a 18650 lithium battery as the 4.12v to simulate the arduino output pins. I carefully electrically isolated all the metal lines with packing tape for now to ensure no short circuits and then I connected the lab power supply pins to the correct locations with alligator clips. Finally I connected the 18650 lithium battery 4.12v to simulate the arduino turning on the A09T mosfet - I did this using the two nickel strips for this portion joined to the battery with neodymium magnets. If I had a 3rd power supply I could get 5v off of I'd have done that but I didn't have one in arms reach so the battery it was. The LED came on and I tested the output line to the motor was indeed 8.07v. I then disconnected the + side of the battery and verified the line going to the motor was 0V. It was - although if I kept the multimeter on that line longer I noticed it would creep up to like 3.4v but something similar happened on my last test run and chatgpt said this was like parasitic capacitance involving the multimeter or something and nothing to worry about. The main thing is it would START at 0v when I first connected and then rise up to 3v or w/e over time on the multimeter screen and this behavior was ok last time so meh. We're good I think.
Where to go from here then? Well I'd say I make the other (lowside) portion of the half bridge and then test the full half bridge to ensure it's all working. I think then my design is validated enough to move into diy flex pcb for some of these portions that are on the layer that goes onto the main beefy mosfets.
-
So armed with my successful electronic test of my prototype highside switch with driving circuit all passing, I determined now it is sufficiently validated to go through the process of converting it into a printable schematic and doing the whole DIY flat flex PCB making and acid etching process to streamline the development of the rest of the motor controller and most likely many more motor controllers as well.
I opted to use photoshop as my circuit making software of choice as I'm very familiar with it and use it often. I first dropped my top view photo of my prototype circuit into photoshop then I redid its layout a bit to make it more compact, moving around copied pieces on the photo to achieve this. Next, I used the pencil tool to color in blue pads and traces connecting all the pieces of it together. I then hid all but this pads and traces layer and printed it several times, tweaking the printing scale until it fit the size of the pieces IRL. 7.5% scale was the perfect fit.
(https://dollforum.com/forum/download/file.php?id=1594527)
(https://dollforum.com/forum/download/file.php?id=1594528)
(https://dollforum.com/forum/download/file.php?id=1594529)
Next, I will need to refresh my knowledge of the transfer paper print and transfer of the ink off of this paper onto the copper clad blank flat flex PCB and then acid etching away all unwanted copper and then removing the ink to reveal the fresh copper traces and pads. Then I can solder all the SMD components onto this. Heck I may even make a solder paste stencil and place components and bake them on. But perhaps just hand solder for now? Not sure. The former is faster in the long run but takes more setup and is quite committing. I'd rather validate my designs even further before going that far.
-
I successfully made a viable flex PCB on my second attempt.
I started by printing the circuit onto a mailing envelope using my laser printer. Then I taped a piece of toner transfer paper for PCBs shiny side up directly over where the print on the envelope was. This way I could use just a tiny bit of the expensive toner paper and know the printer would hit that exact spot again when I reload the envelope in the same spot.
(https://dollforum.com/forum/download/file.php?id=1594880&t=1)
The print landed right on the toner transfer paper according to plan.
I then sanded with 400 grit sandpaper the Pyralux flat flex PCB copper blank and wiped it off with a alcohol prep pad. These actions clear any oils and oxidation and give more bite for the toner to cling to the board better.
I then taped directly onto this toner transfer paper print the Pyralux flat flex pcb copper blank. No need to even take it off the envelope. Just taped it right over it and fed the whole sandwiched assembly through my laminator a few times envelope and all.
(https://dollforum.com/forum/download/file.php?id=1594881&t=1)
When I peeled back the Pyralux flat flex PCB my laser printer's toner was indeed transferred over to the Pyralux flat flex PCB's copper.
(https://dollforum.com/forum/download/file.php?id=1594882&t=1)
I prepared etchant solution mix of 1 part etchant powder to 4 parts water. I just eyed this roughly and think I did not put in enough echant which causes undercutting of the traces under the toner and slower etching. Lesson learned.
(https://dollforum.com/forum/download/file.php?id=1594883&t=1)
I mixed it in a silicone earplugs container. My aim was a small container to make a smaller batch of the etchant to cut down on etchant used since I'm only doing a very small PCB.
(https://dollforum.com/forum/download/file.php?id=1594884&t=1)
(https://dollforum.com/forum/download/file.php?id=1594885&t=1)
The first board I left etching for a couple hours unattended which was a mistake. It was unusable. A ton of the copper under the toner was missing which is called undercutting. I left it etching for too long which causes this.
The second board came out pretty good. But I used the exhausted etchant from the first board which was already too diluted and so the results were meh but good enough to use IMO.
(https://dollforum.com/forum/download/file.php?id=1594886&t=1)
Note: the prints going onto the toner transfer paper are not very high quality and sometimes has missing spots so AFTER transferring it to the copper I used a Straedler permanent lumocolor super fine tipped pen and magnification to carefully color in any missing spots where the laser printer failed to deposit enough toner or the toner failed to transfer perfectly enough. I used stippling method with the pen - just dotting over and over rather than drawing to get max precision for cleanup of the tiny pads and traces on the copper.
Note: I never had to use water to remove the toner paper from the pcb. Just laminating it a few times through my laminator was enough for the transfer to take place and I was able to cleanly peel it away. This meant the toner transfer paper could remain taped to the envelope and be reused indefinitely. I reused it a few times successfully as I dialed in the processes. This is very nice. Saves time for sure.
Note: I did attempt to not sand nor alcohol treat the Pyralux copper PCB blank and toner transfer onto virgin copper blank but it did not adhere well enough so I reverted to the recommended sanding and wiping after all. Was worth a shot to save steps but did not work out.
Note: I used heavy paper setting in Photoshop during the print dialogue settings because the normal print settings were kind of messing up for me. I also think this printer is not very well suited for this. My other laser printer has a "best" quality option and did very nice prints but this one is a cheapo I'm using and only has "fast" quality but worked well enough nonetheless for the most part.
Note: I assumed I could use this etchant over and over and over but chatgpt said it gets exhausted and loses efficacy and should only be used once. Some acids people made online you could use over and over but I guess not this type not sure.
Note: the acid etchant I'm using says it only releases oxygen so the fumes I guess are not bad like some other kinds of etchant - correct me if I'm wrong on that though.
Note: I used a q-tip and lacquer thinner to remove the toner after the etching was done.
-
Ok here's the populated board. I tested it with 5v positive and ground and the LED came on so it is for sure not shorting and has continuity so is most likely all working. The next test will be the full low-side switch with this board acting as the drive of the main mosfet for the switch. And once that is validated we can test the entire half bridge (both high and low-side switches). If that checks out, it's all rinse and repeat to make the full motor controller (which is just 3 total half bridges).
(https://dollforum.com/forum/download/file.php?id=1595205&t=1)
note: I just wanted to hold off on attaching the heatsink for the moment as I validate the first half bridge and once that checks out electronically then I'll get the heatsink attached and go from there.
-
I have two great breakthroughs to announce.
First, it suddenly occurred to me that I don't have to print onto PCB transfer paper and then transfer that over to the copper clad Pyralux flat flex PCB but instead I can simply tape the copper clad Pyralux flat flex PCB directly onto my envelope and feed that through my laser printer directly. See, I previously ruled this out when originally researching this stuff because I was planning to use FR-4 PCB which is not flexible nor flat enough to feed through a printer directly. However, now that I am using flat and flexible blank PCB there's no reason not to feed it straight into my laser printer that I'm aware of. Now I haven't tested this but if it works it's a game changer. Will make DIY PCBs that much faster and more streamlined to make!
Next, on the subject of attaching the 6 solder wick braids to the mosfets, I was struggling going through the various methods whereby I can tightly clamp it to the mosfet drain and add electrical isolation barrier to the connection point. It's very tight spacing and has to be a very tiny clamping mechanism and the clamp from most directions would have things getting in the way of any clamp design I visualized. It was a nightmare problem IMO. However, my solution I came up with today is game changing: I will simply solder the braids directly to the mosfet drain! This will maximize conductivity off the drain into the braids due to the metal on metal direct connection and eliminate all need for any kind of clamping at all there. Unfortunately, this will make these braids live electrically, but it occurred to me that this is not a big deal. I will simply wrap them in fiberglass window screen to allow them to have great airflow and breath-ability for emissivity of the heat they will be wicking off the mosfet drain and the fiberglass window screen will also act as a physical barrier to them contacting other live metal parts. Window screen is also non-conductive and has good abrasion resistance IMO. I don't anticipate these short wire braid runs to have much contact with anything as they are going to be making short runs from the motor to the water cooling pipe anyways and the exoskeleton mesh that holds up the rubber skin will create spacing and cushion contact bumping or w/e coming from the outside. All in all I think this is a safe solution for the most part and we'll have fuses anyways to prevent major problems in the low risk event of two neighboring live groups of solder wick braid breaking out of their window screen and contacting eachother thereby shorting the circuit. I just see this as highly unlikely but it's covered by the fuse in any case.
That all having been said, the electrical isolation barrier stage we now can place at the location where these solder wick braid ends attach to the copper liquid cooling pipe. There at that attachment point I'll put my electrically isolating thermal tape between the solder wick braid and the pipe and clamp things down by tightly wrapping it in electrical tape at the connection point. This is trivial to achieve compared to doing this at the location of the mosfet drain. So we kicked the electrical isolation and clamping problem further downstream than the mosfet drain connection point in order to make the problem a piece of cake.
Note: chatgpt said I should tin the braided copper solder wick to prevent oxidization of it which would potentially lower its emissivity. Not sure I agree on this though but I may do it just to be safe we'll see. I'd use MG Chemicals Liquid Tin to do this which I already have on hand for tinning circuit boards.
-
I did some research of some loose ends today on chatgpt and discovered that my .1mm x 4mm x 60mm sections of nickel strip on my bldc motor controllers that run from the battery to the motor controller mosfets and from the mosfets out to the motor are too high in resistance and at 30a they would within a few seconds get so hot that they would desolder my low temperature solder paste. So to solve this I will be placing two side by side solder wick braids hugging the underside of the nickel strips which will lower resistance so much that temperature will stop being an issue. They will be a combined .1mm x 4mm x 60mm. Then on future mosfets for this portion I will just use the solder wick braids for this section and not use nickel strips at all because they add too much resistance under this high of amp flow. The 2430 BLDC motors are rated to 25a continuous so my conduit has to also handle that easily without overheating.
Another really cool discovery I made today was on the topic of measuring current. I'd been putting this off till now but finally got around to deep diving it with chatgpt and discovered something shocking. So basically it was saying to use a shunt resistor inline with the ground side running from the motor controller to the battery. All the current of the motor controller (30a on the high end) will pass through this resistor as its only path. The special thing about a shunt resistor is that its resistance is so low that it doesn't affect voltage or amps a whole lot. I asked chatgpt if I can use nickel strips as my shunt resistor since a smd shunt resistor it said would overheat fast at 30a. It said yes! So I'll be using a .1mm x 4mm x 30mm section of nickel strip as part of my wire run going from the motor controller back to the battery on the ground side. This will act as my homemade shunt resistor. Now the way the arduino will read the amount of current is the analogue input pin will feed into the upstream side (closest to motor controller) of the shunt resistor section of nickel strip and the arduino ground will attach to the downstream side of this nickel strip shunt resistor. It will measure the tiny amount of voltage drop that occurs on account of the shunt resistor's resistance. What is really cool is that the voltage drop changes at this resistance and amp level are read granularly enough by the Arduino analogue input pins that I don't even need to amplify them to read them in meaningfully. Some things like strain gauges provide such tiny resistance changes that you have to use a OP AMP amplifier to be able to read the changes in with your analogue input pin of your arduino to detect them meaningfully but in this case, the resistance changes are large enough and the analogue input pins are granular enough to be able to read them in without any amplification. This means reading in the current for my motor controllers requires ZERO components! It's literally just nickel strip which I already had for the battery tab making and some jumper wire or w/e to take in the readings and that's it! No parts to buy. I had bought some hall effect based current sensor kits and they are not needed at all. I wasted my money on them in the past because I did not know about this shunt resistor option at all at the time. Had I known I would have never bought hall effect based sensor kits - a waste of money. Not to mention they were relatively huge whereas this takes up like practically zero space to measure a shunt resistor section of conduit between the battery and motor controller. So it's awesome news!
Note: the current sensing is meant to tell my control system anytime a new unexpected load has hit the motor so it can slow down the flow rate of electric to the motor to prevent burning out something for example or it can also detect any kind of snags or w/e anything getting stuck. It can also help monitor amp flow for the sake of holding the motor in place with stall current kept low enough to prevent overheating etc. It can also act as collision detection if trying to monitor its interactions with its environment and know if something has hit something - which is insanely useful for situational awareness. So it's extremely useful and basically not even optional frankly. To now know that adding this feature is free and super easy to implement and will take up practically ZERO extra space is very exciting to me.
Note: my diy shunt resistor (.1mm x 4mm x 30mm section of nickel strip) will have a .005 ohm resistance which is pretty much perfect for my use case it seems (unproven but chatgpt sounds sure of it). It will enable me to monitor the range of 5a to 30a and detect a change in amperage with like 1a granularity.
-
I used my jumbo Weller W100P soldering iron to attach my 6 solder wick braids to the back of the highside mosfet today and it attached instantly without a hitch. I used low temp solder paste liberally between the two on both surfaces then with my left hand smashed then together with the tip of a xacto knife pressed down onto the solder wick braids from the back. Then I brought in the giant soldering iron and it liquefied the solder in about 1 second despite all that metal involved because it holds such a massive amount of thermal energy that it can deliver on demand very quickly. Such a easier time than trying to do bigger soldering jobs with a micro tip regular soldering iron which often ends with cold joints and stuff. Also since the liquefication went so fast nothing nearby desoldered which is a huge plus.
(https://dollforum.com/forum/download/file.php?id=1603156&t=1)
Next up: add the solder wick braids to the underside of nickel strips to lessen resistance there and then insulate this highside switch assembly and install against motor and start finalizing wire run plans. Then I can rinse repeat this for the lowside switch assembly. Then I'll have one of the 3 half bridges done for the motor controller.
-
So it hit me that having these braided solder wick wires live all the way to the water cooled pipe distal attachment point is not necessary. And could cause some EMI or noise related issues that is avoidable if I do the following: I can simply cut them off 1/2" from the mosfet, stick thermal tape on one face of the cut off stubs, then stick the rest of the braided solder wick wire run against that thermal tape, then wrap this joint tightly with electrical tape. Finally we then electrically insulate the braided solder wick that is live but leave the braided solder wick section that is now no longer live completely exposed on the duration of its 3"-4" long run from near the mosfet to the water cooled pipe. This way we have electrical isolation near to the mosfet, no antenna effect, no need for window screens now, and no live wires hanging out that aren't properly insulated. Thermal conductivity is reduced negligibly with this solution. This should be trivial to implement as well. It's the perfect solution here and very fast to implement. It may even be slightly less work than dealing with window screens would have been.
-
Well I tested printing directly onto Pyralux copper and it was a massive failure. Not even one spec of ink stayed on it and the print came out a inch off the location of the copper. Chatgpt said this is because copper can't hold a electro static charge long enough to take ink onto itself or w/e. Ah well I can fall back to the method I already used successfully.
On that note, I realized printing my blue circuit is bad since a black and white printer won't print as densely and darkly a blue thing as it would a black thing so I have to make my circuit black before printing it. Also I should set my dpi to 600 dpi instead of 1200dpi which will create denser thicker prints for better transfer. Also I should select label paper instead of heavy paper which will work better. Also using Lumicolor Straedler pen is not good as it can be undercut easily supposedly. Better to use oil based marker instead. So I ordered that in 0.3mm tip. These are all improvements chatgpt suggested and I plan to use when printing onto the pcb transfer paper and hand touching those up if needed. I'm getting ready to make a bunch of flex pcbs for finishing this motor controller. I already started doing it.
Another disaster happened to me as well: my highside circuit I just soldered the solder wick wire onto, when I was analyzing it closely on the front I noticed that excess solder from the drain side of it oozed and dripped toward the front side of it and attached to the gate pin! I heated up that attachment point from the front side and my capacitor and resistor from gate to source both came off from the heat! Anyways I heated it up to remove that short circuit and used a xacto knife to wedge between the gate pin and back of mosfet's drain pad which had a solder bridge. I got through the bridge successfully but now have to redo the gate to source resistor and capacitor. Ugh! Two steps forward one step back. Then while inspecting and cleaning everything I moved the control circuitry a bit too much and it broke off for the 3rd time! So that has to be done again. This time I'm using flat flex for it. I've had it with the non flat flex variant breaking. The flat flex is way more solid mechanically. So that's a redo needed. Ugh.
Then to top it all off, the solder wick braids recent idea I had to electrically isolate their run near to the mosfet so that they aren't live for very long - which had to do with wanting to eliminate any short circuit risks in their longer run as well as remove any potential for antenna affects - yeah... well after cutting them all in half to do this transition idea, as I was doing it, I realized the surface area where the hand-off takes place between one section of solder wick braid and onto the next seems very small to me (2mm wide by 6mm long) and it seemed to me that the passage of heat across this tiny bridge of thermal tape might be severely compromised and would depend on how tight I made the squeeze of the two pieces of solder wick braid together as well. And I'm not sure I can clamp it tight enough with just tape wrapping it firmly. And if it gets quite hot I'm concerned electrical tape will get gooey and come loose over time and not hold it well. I'm not sure how tight kapton can wrap things I've never used it before so I'm inexperienced with using it and trusting it is hard without experience working with it. This all cumulatively gave me enough doubt that I said heck with it, I'm going to revert to the former plan to just run it live over to the water cooled pipe 3-4" away and use the thermal tape at that junction point where it wraps the pipe. This ensures alot of metal volume is directly tied to the mosfet which means more heat sinking directly with little risk of trapping heat near mosfet - which could happen if my thermal tape junction of copper braid to copper braid were to fail for example by being pulled apart by accident for any reason. Too much risk there IMO. And the risk of a short on account of live wiring it for 3-4" with the live wire sheathed in window screen to emit heat freely but not touch anything I feel is low enough risk IMO. So whatever route I choose has tradeoffs and I feel reverting to my former plan is more robust and foolproof thermally with some minor electrical risks that are mitigated by fuses and careful execution in general. So yeah I had to solder the cut pieces of solder wick braid back together again which was another pain.
Note: the next time I solder the heatsink braids onto the drain I plan to use less solder paste so it doesn't ooze and drop forward onto the front circuitry on the front face of the mosfet by accident. I also plan to insulate the front side's circuitry beforehand so even if solder did ooze that way the insulation barrier would prevent short circuits and make the oozing no big deal in theory.
So yeah it was a tough session but I learned alot from the mistakes etc.
-
So I did manage to add a pair of braided solder wick wire as a added layer over the nickel strips of the highside mosfet setup and I insulated that with red electrical tape folded over it. I also insulated everything else in sight for the most part. I lost the original control circuit so I made the replacement flat flex pcb style which should be more robust. I also added a yellow 30ga wire for the 20v input line of the gate pin of the main mosfet. I also got my fiberglass window screen mesh ready to be installed to insulate the solder wick wires acting as heatsinks. So this setup is getting close to install ready now but I want to test it again to make sure its still working after all the major changes and messing with it so much.
(https://dollforum.com/forum/download/file.php?id=1609598&t=1)
(https://dollforum.com/forum/download/file.php?id=1609599&t=1)
On another note, I noticed that stacking the 0.1mm x 4mm x 100mm nickel strip plus braided solder wick to reduce resistance and increase conductivity made the lines a bit thicker than I'd like, especially after adding tape. So to resolve this I decided to roll with 0.2mm x 6mm x 100 mm hand cut out strips of pure copper plate. I was not aware of this option before but I was able to find copper in .2mm thickness in a roll on amazon that I can use for this. With this thicker size and the much lower resistance of copper I should be able to run 30a through it with less than 1w of waste heat which is great. And this will still give me a way thinner result than what I used on this first one while lending lower resistance by getting rid of nickel strip entirely for the high amp stuff (aside from the shunt resistor nickel strip which I still plan to keep).
(https://dollforum.com/forum/download/file.php?id=1609600)
-
I was randomly talking to chatgpt about how I have been feeling burdened by having to make my own BLDC motor controllers for my robot lately and it randomly mentioned integrated half-bridge power modules as something I could use to cut down on my labor load in making these motor controllers. This immediately stood out to me as something I'd never heard of and something intriguing. I have so far been working on my lowside switch and highside switch which together form a half bridge. Many solder connections have been involved and alot of discrete components are involved. The concept of an integrated half bridge on a single chip - meaning two big power mosfets and all the drive circuitry for those power mosfets all condensed into a single chip would be a huge reduction in size and component count as well. So I researched if any are able to do 8v 30a for my 2430 BLDC motor's needs. Turns out there are some out there. At first I was looking at Texas Instruments CSD95377Q4M Half‑Bridge Driver (30 A) which can do 30a continuous so perfect for me. However, I didn't want to lock myself into a single vendor chip that may one day be discontinued. I prefer something ubiquitous with many competitors making it that can be purchased from aliexpress. Something commodity level. This way I future proof it and don't have to worry about any one manufacturer discontinuing parts I'm using and prices soaring because of that or simply the part becoming unavailable. So after a bit further digging I found CSD95481RWJ QFN chipset on aliexpress sold by several vendors and one was under $1 each. So it is equivalent to two power mosfets plus all drive circuitry for each power mosfet all for under $1. This one also has 60a continuous rating. It is only 5mm x 6mm in size which to me is insane. This is so much smaller than the setup I've been working on yet just as powerful. They are usually used for tiny buck converters and used directly on videocard PCBs and in servers and in automotive PCBs and much more. In any case, using 3 of these half bridge chips you can drive a BLDC motor. The consolidation of so many parts into such a tiny package is truly blowing my mind. So I ordered 60 of these chips - enough to drive 20 BLDC motors. I am leaning toward using these for all my motor controllers if working with them is easier than working with discrete components like I have been. They are cheaper to work with I think - I'd have to run the numbers on that though. They even have built in temp sensing we can read in which is a bonus. Their built in current sensing will not work for BLDC motors so I'll still need my shunt resistor current sensing circuit setup external to it but that's ok. All in all these appear to be a game changer in terms of reducing part count so less potential points of failure and also reducing board footprint so miniaturizing my electronics even more which is very good for us. I'm still needing to work out now how I want to hook these up in terms of PCB making for it and any discrete external components needed to support it. It is also top cooled which is interesting. I'm envisioning using silicone thermal adhesive to glue on a copper pad that has my braided solder wick wires already soldered to it. These will carry the heat away to my water cooled pipe system.
(https://dollforum.com/forum/download/file.php?id=1617285)
I'm kind of amazed that nobody really seems to use these for BLDC motor controllers. They seem perfect for it. Maybe I'll start a trend. Assuming I don't find out the hard way why they are never used for this application!
note: the full product title: "(5pcs)100% original New CSD95481RWJ 95481RWJ CSD59950RWJ 59950RWJ QFN Chipset"
note: for my previous BLDC motor controller design I was needing to use 6 digital IO pins to drive a single BLDC motor controller's 6 power mosfets by way of their control circuitry. But for a BLDC motor controller design using 3 CSD95481RWJ H-bridge chips, I will only need to use 3 digital IO pins on the microcontroller. These CSD95481RWJ H-bridge chips use a pwm pin that is a tri-state pin - you can have high, low, and floating as the signal you send to it from your microcontroller. Digital output high and low are the usual digital output modes but the floating mode you do in your code by configuring the pin to be a digital input pin which makes it a floating pin. These 3 states fed into the chip makes it either give you V+ as its output or V- as its output or just off/floating as its output. This corresponds perfectly to the normal h-bridge 3 states we'd be using with our discrete components previous microcontroller design. So this savings in total digital I/O pin usage on the microcontroller means you can drive more motors per microcontroller in theory which is pretty cool.
-
Well I deep dove into the CSD95481RWJ IC route. I estimate it will cut the work in half roughly for every motor controller made and cut the size taken up by about 60% compared to my previous discrete components approach.
Now I will note that I did come across the BTN8982TA which is rated to 40v and can handle 30a continuous 50a peak short burst. But it's TO-263 form factor so about 4 times as big as the CSD95481RWJ. It also costs about $2 each so double the price. It's not a bad option though all things considered but just not quite as good as the CSD95481RWJ for the reasons mentioned. I note it here so I don't forget about it. It can be a great option if the CSD95481RWJ doesn't work out in the end or something.
Anyways, for the thermal concern - which is my biggest concern, I plan to top cool the CSD95481RWJ using a .2mm plate thermal siliconed into place on top of the CSD95481RWJ and then solder a bundle of 4 braided solder wick wires to that and run that off to the water cooled copper pipe about 4" away. The top cooling only handles about 30% of the cooling according to chatgpt. The most important 70% is from the bottom cooling through its pads on its bottom. For this I plan to use double stacked .2mm thick copper plate soldered to its IC pads. So that's .4mm thick. Also it will be around 2mm wide where it attaches to the pads. It will then route out from under the chip and swing upward into free space and head over to the 8v+ and 8v- buses coming from the 8v motor battery banks in the robot's lower torso. These thick copper traces I will fork off of with braided solder wick wire right near the CSD95481RWJ IC chip for thermal conductivity reasons. This braided solder wick wire will be live so I will wrap it in fiberglass window screen so nothing can touch it - preventing short circuits. It will then be electrically isolated from where it connects to the water cooled copper pipe with thermal conductive tape. The braided solder wick wire attaching to these thick copper traces will be a bundle of 4 per trace. The various decoupling capacitors this chip calls for I will connect to its output pins using flat flex PCB DIY hand made. I'll be attaching this PCB first and attaching the thick copper traces to the underside pads second as a separate layer that goes underneath the flat flex PCB layer. The flat flex PCB layer will mostly stay around the outsides of the chip and have its center cut out and removed - the part of it that would get in the way of the underside main pads under the chip. So the flat flex PCB will just hug the outsides of the IC mainly in a U shape around the chip leaving the center of the bottom of the chip free to solder to with my thick copper traces.
Note: the thick copper traces will be cut out with scissors from a roll of .2mm copper sheeting I bought on amazon which I mentioned a few posts back. Double stacking it wil double its thickness and increase its conductivity both electrically and thermally.
Note: in a usual setup with this CSD95481RWJ IC, a multilayer board with a array of vias is used to bring the heat downward off the chip and into another lower layer within the multilayer board where it can then radiate on said layer outward in every direction. In my approach, I use thicker traces than the layers of a multilayer PCB has so I have alot more local copper in play. Then instead of the heat transferring down and then outward in all directions on very thin copper, mine travels down then in a single direction outward away from the IC on that trace. The trace will need to be as wide as possible as soon as possible. I expect to get it from 2mm width - the width of the pad - to 5mm width within a few mm. This rapid transition to a wider width combined with the use of much thicker copper compared to a multilayer PCB's copper thickness of its layers means I should be able to exceed the thermal performance of a multilayer board using my approach. Especially since I also plan to quickly fork off the main traces with bundles of 4 solder wick wire braids that will carry the heat off to a water cooled pipe 4" away.
Note: in my attached schematic I only show a single CSD95481RWJ IC because they are all wired up the exact same way. It's just doing it 3 times for each of the 3 phase wires of the BLDC motor.
Note: I will use a single electrolytic capacitor per motor controller also not pictured in the schematic.
(https://dollforum.com/forum/download/file.php?id=1617833)
-
OK, so when I was thinking of using both my discrete components motor controller design parts I already made and then also separately implementing the integrated half bridge IC design going forward, it hit me that the 8v- and arduino gnd tie together on the half bridge IC by necessity but this ruined their intended isolation I needed for my discrete components motor controller design particularly for the lowside switching portion of that schematic. On the lowside switching portion, the little mosfet has 12v- and arduino gnd tied to its source pin. If on the integrated half bridge I also have to tie arduino gnd and 8v-, then that means 12v- and 8v- and arduino gnd are all tied together always.
That completely ruined the necessary isolation between arduino gnd/12v- and 8v- that I had intended to be in place for my lowside switch setup. So that was bug #1 freshly introduced that I would then need to solve for in my discrete components motor controller design. When studying this out on the discrete components motor controller design, another error hit me: when any lowside switch turned on in the design, the 12v- dedicated power supply gnd and the 8v- motor supply gnd become connected as long as that lowside switch is on. Since every lowside switch had always access to 8v gnd on its source pin, then even one moment of 12v gnd and 8v gnd attachment anywhere on the robot would cause every lowside switch in the entire robot to immediately turn on at the same time. So if any turned on, then all turned on. This was a huge oversight. For some reason since I only designed and focused on one half bridge conceptually at a time, I did not consider the effects one half bridge has on its neighboring half bridges. This just never occurred to me. I guess conceptually I envisioned that every half bridge had its own personal 12v ground from its own personal 12v supply that was electrically isolated from the entire rest of the robot. But of course that's not practical even if it is technically possible. So in testing, things did work, but would have failed as soon as I tried to test more than one half bridge at a time. So I caught this bug before testing revealed it.
I discussed this horrible situation with chatgpt and it taught me that in a complex system like a robot, grounds of all your different supply rail voltages cannot be relied on to be isolated from one another like I was treating it. Even if at times they were momentarily, one switch, one change and suddenly they are not and it all becomes a common system ground again. So if I can't safely assume a ground for any given voltage is safely disconnected from the grounds of other voltages, I should not rely on switching on and off access to any particular ground to any of my lowside switches. Instead, I should be shorting the gate driver of the lowside switches to ground to shut them off rather than messing with their source pin's ground connections like I was before. I am to leave the source pin's ground connection as 12v- and its gate connection as 12v+ at all times except when I want to shut it off - at which point I short the gate pin to gnd using my logic level mosfet to do so.
The fix was very straightforward and minor: I just had to add a 100ohm resistor in series with the gate pin of my big power mosfet lowside switch and then reroute my little mosfet a09t drain pin to the big lowside mosfet's gate pin instead of its source pin. The connection to its gate pin must be downstream of that 100 ohm series resistor so that the path from the big mosfet's gate pin has almost zero resistance when traveling through the little mosfet's drain line and over to its source line into ground. This way when you turn on the little mosfet, the big mosfet's internal capacitor quickly empties out, flushing into the path to ground created by the little mosfet and that discharges the big mosfet, shutting it off. When you want it back on, you shut the little mosfet off, which allows the big mosfet's internal capacitor to charge up again, which turns the big mosfet back on. So the setup now acts like a normally on relay.
Note: the resistor on the drain line of the little mosfet that we used to have when it fed into the source line previously is now removed. We want no resistance on there because that would impede the little mosfet's ability to discharge the big mosfet's internal capacitor in a timely manner. We want to be able to not only discharge that capacitor quickly but also direct all incoming current from the 12v+ line that makes it past the 100ohm resistor heading for that big mosfet's gate into our ground path. This rapid redirect flushes so much of that already limited current that hardly any can make it inside the gate of the big mosfet which causes the gate of the big mosfet's voltage to approach near zero volts. So it's called a "pull down" path to ground.
Attached is a photo of my schematic before and after the fix.
(https://dollforum.com/forum/download/file.php?id=1619099&t=1)
Attached is a photo of full updated schematic with the changes in place.
(https://dollforum.com/forum/download/file.php?id=1619100&t=1)
That all having been said, this discrete components original bldc motor controller design, now fixed, is worth keeping archived, but is now basically abandoned now that I have access to the time, money, and space saving shortcut of my integrated half bridge IC based design. It's kind of sad to abandon something I spent so much time on, but who knows, I may still use it if I ever come across a motor that I can't find a cheap half bridge integrated IC for in the future. It's a great schematic to have at the ready for that scenario.
-
Ok so I was thinking now that each half bridge is just a tiny IC rather than a pair of hefty power mosfets, the space taken up overall by my entire bldc motor controller is going to be about 3cm x 1cm x 2mm which is insanely small for 30a continuous at 8v motor controller! This realization caused me to reconsider whether I even need to treat this as a single motor controller cluster that has to be sat like a horse saddle onto the side of my bldc motor - my original intention for my discrete components original design for my original bldc motor controller. What I realized instead is that things are now so small that I can simply build a half bridge for each phase as a inline element nested inside the cable run leading to each phase wire of the bldc motor. So instead of having a dedicated spot for each motor controller, I'm going to have just a slight bulge in the phase wire leading out from the bldc motor and that bulge will contain the half bridge that handles that phase wire. All nested inline. This is the easiest way to implement and most streamlined I think. It also means the whole motor controller will just be "floating" in midair, not actually mounted to any motor or anything at all. Just part of the wire harness nested right in there. This is a radical approach IMO. Only made reasonable by the fact we miniaturized the design by such an insane degree.
So the previous version of the schematic was intended to be mounted to the side of the motor like a horse saddle and had an l shape so inputs would come up from bottom and outputs out to left side toward motor phase wires. These L shaped half bridge setups would be stacked next to eachother side by side. In the new variation everything is inline, inputs coming from right and outputs exit out left side to motor.
Here's the updated inline variation of the schematic (no longer L shaped flow like before).
(https://dollforum.com/forum/download/file.php?id=1619348&t=1)
-
Ok so I realized I don't have to feed in 8v+ from an external wire when I can just pull it from a neighboring pin on the chip that has 8v+ already fed to it from one of the big 8v+ copper traces attached to one of the big 8v+ pads on the underside that connect directly to one of the side pins. That side pin can then be routed to any 8v+ requiring pins if I can find a path for this routing - which I did find. So that is one less external wire input needed - bringing total external input wires needed to 3 instead of 4 as far as the 30ga wires I need to attach. So now all I need for 30ga wire attachments are 5v+ from arduino, GND from arduino, and PWM from arduino. This saves work and simplifies the wiring so its a great improvement.
Oh and I also did the same thing for the 8v- feed, pulling it from a local pad rather than a external wire feed for that.
(https://dollforum.com/forum/download/file.php?id=1621884&t=1)
Also, I have separated out the PCB traces themselves and made them black instead of blue for printing them onto the PCB transfer paper and laminating this onto the blank Pyralux flex PCBs for etching them. I also mirrored it since it prints and laminates backwards onto the PCB.
(https://dollforum.com/forum/download/file.php?id=1621885)
-
So I ran into some issues trying to make the DIY flex PCB for my integrated half bridge IC chip. This chip has extremely fine 0.4mm pin spacing so the PCB has to be insanely accurate. My previous discrete components BLDC motor controller variant enabled me to create much more crude and less dialed in flex PCBs and things still worked. But with this flex PCB it has to be very dialed in and with very high execution precision. This is no joke. The first issue is that my laser printer does not adhere well to the pcb transfer paper I bought on amazon. It prints on it with some of the toner showing up mirrored a inch or so away from where the print originally lands onto the PCB transfer paper.
(https://github.com/artbyrobot/realistic-humanoid-robots/blob/main/laser-printer-adhesion-issues-to-amazon-pcb-transfer-paper.jpeg?raw=true)
This means the ink isn't setting onto the transfer paper enough and is coming off onto the fuser roller or something and that is corrupting the fuser roller. This can destroy my printer's performance over time and cause improper fusing onto all prints going forward even for normal office use which means addresses I print on envelopes are smearing off while in transit and envelopes are being lost in the mail system for me. This is VERY VERY bad. So I had to ditch using this transfer paper.
Thankfully chatgpt recommended using glossy magazine paper and so I gave that a try. I used Psychology Today magazine paper and the print went onto there PERFECTLY. I used 600 dpi setting, heavy as paper type. I prepped my copper flex PCB blank (Pyralux) with 400 grit sandpaper followed by alcohol prep pad wipes. Next, I laminated the glossy magazine paper print onto my copper flex PCB blank (Pyralux) with my laminator a few passes. Next I soaked the magazine and flex PCB sandwich in 110F water for around 30 minutes which turned the glossy magazine paper mushy/pulpy. I then rubbed the paper repeatedly with my fingers working from the outside edges and was able to roll it off gradually and gently. It came off in two layers. It leaves a bit of pulp residue behind on the pads but that is ok it doesn't affect the etching process later you can leave that. And with this method I got the cleanest traces on there EVER.
(https://github.com/artbyrobot/realistic-humanoid-robots/blob/main/integrated-half-bridge-bldc-motor-controller-pcb-making.jpeg?raw=true)
(https://github.com/artbyrobot/realistic-humanoid-robots/blob/main/integrated-half-bridge-bldc-motor-controller-pcb-making-closeup.jpeg?raw=true)
But when I went to etch this clean PCB with toner in place, things fell apart again. I used room temperature water with my Ammonium Persulfate crystal and water mixture. So it was 68F water. I did not agitate the etchant much. The etching took about 2.5-3 hours! That is horrible etching speed. The larger copper planes took their dear time to evaporate and meanwhile the finer traces had undercutting so bad that the entire copper under the toner etched away and evaporated and the toner came off having nothing to stick to anymore and whose sections were lost. The total etching time is supposed to be no more than 5-15 minutes. 3 hours is totally unacceptable. I found out from chatgpt that the reason it took forever was I failed to heat the etchant to 110-120F and I failed to agitate the mix (stir or vibrate or w/e helps). I also learned from chatgpt that for every 10F increase in temperature of the etchant, the etching time cuts in half. So a increase to 110F will mean the etching time should come down to the 5 minute range pretty likely if I also agitate well. The instructions on the container of etchant crystals said room temperature and no agitation is fine. THEY WERE WRONG for SURE on that.
So to address perfecting the etching process I plan to get a AC hot plate with temperature adjust which I already own - one for like pans or kettles cooking/heating. I also determined that the easiest way to agitate would be to put the etchant and PCB in a small container and create a apparatus that lifts and lowers one side of the container in a rhythmic way so that it rocks the etchant back and forth across the PCB. Below is my simple apparatus design for that. The advantage of this approach is its free if you have the very few parts needed. I can power it with my lab power supply. The n20 gear motor is like $1. Super easy to make. Can handle my 15g of etchant sloshing easily. Simple to make. Does not have anything going INSIDE the acid which would then be spinning and crashing into the PCB and possibly causing issues there. We want just a bear minimum amount of etchant batch per PCB job and so even a spinning stir rod with magnet setup would be hitting the PCB and tossing it around violently etc I didn't want that and didn't want acid on that and having to fish it out and clean it of acid. Prefer nothing going into the acid but the PCB itself. So rocking the whole container makes sense for this and resolves that problem.
The rocker apparatus consists of a n20 gearmotor ($1 on aliexpress), a little wheel (paper and superglue composite wheel), string, a little block to get the motor up higher in placement than the etchant container. As the n20 gearmotor rotates it lifts the string, raising up one end of the etchant container. As it reaches 180 degrees of rotation (6 o'clock) it has lowered the etchant container back down. It repeats this raising and lowering of the container over and over in a cyclic pattern which will cause the etchant solution to slosh back and forth over the PCB improving the rate of the chemical etching reaction and moving copper ions away from the PCB surface being etched more efficiently. No pwm motor controller is needed I don't think since you can change the rock speed by changing voltage setting on the lab power supply and/or changing radius of the wheel that is turning and doing the lifting and lowering action.
(https://github.com/artbyrobot/realistic-humanoid-robots/blob/main/etchant-container-diy-rocker-agitation-device-plans.jpeg?raw=true)
-
So I was randomly watching YouTube recently and saw a George Hotz past broadcast entitled "George Hotz | Programming | Welcome to Gas Town and the future of Computer Use | Agentic AI | Part 1". It kind of shocked me to see this. I was under the impression for some years now that vibecoding was for total noob programmers who were incompetent and horrible coders that were happy to throw together some absolute trash bug filled code with LLM help and call it done. And that were they ever to need to go back and fix the code and remove bugs, it would be more trouble than it was worth due to the horrible code the LLM output. That it would be easier to rewrite it all from scratch at that point than to try to fix its bugs. I'd been watching this space closely though. That was the consensus I thought was at hand. But then this video threw a monkey wrench into that consensus. Here, a world renowned god-tier coder in George Hotz was using agentic AI and saying its the future of coding. Kind of blew my mind. I then deep dove into agentic AI, how agents work, what is the agentic loop, what are agent tools, what are agent skills, what is good vibe coding practice, what are good vs bad vibe coding methodologies, how much does it cost, etc etc. I discovered something called Claude Code and Codex and OpenCode and OpenClaw and people raving about these tools or warning about them and making fun of them. It is a incredibly polarizing topic with people adamantly for and against it all. I even listened to a 11.5 hour long audiobook called Vibe Coding Audiobook by Gene Kim, Steve Yegge. It was a huge deep dive for me.
In the end I drew several conclusions or hypothesis and chose the following stances: I think full blown vibe coding infrastructure low level important lengthy and complex coding projects is not a good idea now and maybe ever. But I think LLM assisted coding can do it. Vibe coding where you don't even really look at the code at all and trust the LLM and agentic AI using the LLM completely is probably only doable for very simple things and will be buggy and ugly code in many ways. Not useful for 99% of my goals. Maybe that can work for front-end web UIs but nothing intensive and low level like computer vision, game engines, AI dev, making an OS, making speech synthesis or speech recognition engines, SLAM, etc etc. It would be horrible for that IMO.
So for my goals, how can I best use LLM assisted coding? Well, my chosen LLM at this time for this is Chatgpt. How will I use it? Well I can use it to co-develop plans and algorithm workflows for modules or sections of code one step at a time. Working through it all. Then once that is done and saved, we can go step by step together writing the code or editing existing code as needed to bring about successful steps one at a time and test it thoroughly as we go. Now in some ways I had already been asking Chatgpt some questions while I code and getting SOME coding help as I code when I used it a few years back as a stack exchange substitute or ask a friend type assistant. At that time I didn't have it producing much code for me though. You can see videos of me coding this way on my YouTube robotics playlist. But I am now planning to take LLM use for coding assistance to a whole other level in a novel way I came up with. So on my IDE of choice, Dev C++ 4.9.9.2, there are no copilot AIs or w/e to code along with you and those are mostly autocomplete AIs anyways - they don't code for you. So that's not what I want. I also don't want to use any other IDEs for various reasons we won't go into here. So what I decided to do is just make my web browser full-screen and stay on the chatgpt chat interface THE WHOLE TIME I am coding. No alt tabbing, no terminal uses, no IDEs. Just stay on chatgpt web browser and that's it. For the most part. That's kind of the aim. So how can I code like this and test the code and whatnot then? Well basically chatgpt and I came up with the idea of creating a program that we called "The Orchestrator" that would run on my PC and read the chat I'm having with chatgpt and read the code that chatgpt writes or wants to change in my codebase and it would then validate that code change request or code snippet addition, make sure it fits our desired formatting and coding style, make sure it doesn't break any rule or screw up anything, possibly query another LLM AI with a submission of that code change and a copy of the surrounding code module it is changing and ask if it will break anything, if it will do what it claims it will do, etc etc etc. And after a extensive series of validation steps, the Orchestrator will either report back that the code was faulty with a reason why it was faulty or it will determine the code was good and passed checks. It will report back via a popup window message and/or possibly optionally text to speech so I hear it talking to me verbally which might be kind of cool. It would populate my clipboard of my mouse and tell me to paste its response into chatgpt. Which I would then do and hit enter to submit the response. Chatgpt would then see what it screwed up and rewrite it after apologizing or w/e. This would rinse repeat until the Orchestrator approved the code. Upon approving it, it would bring up a popup window UI that would act as a IDE containing my codebase file we are editing, the ability to scroll up and down to read my code, etc. It would highlight in green the new code chatgpt was recommending we add within my codebase, giving a green background there. Or if it was a code change chatgpt had written, it would split the screen of that section into two halves. On the left half would be the original code being modified. On the right half would be the changed code proposal with the actual changes highlighted with a red background. I would read both at that point, make any modifications I wanted right there in that window, and hit ok if I approved. So then my job besides co-planning with chatgpt and talking back and forth till I like the plan with the code steps is to read and approve all code changes before they go in and make any final tweaks. Ideally I no longer actually write the code, I just help plan and submit approvals. I have to understand the codebase deeply the whole time, I give all approvals, and I at no point let the LLM just go haywire on my codebase. It's relative to full automation with a local AI agent a slow and methodical process where I retain full understanding and control the whole time. This I feel comfortable with. And this setup I described is my planning coding workflow. It does not have me using the terminal nor an IDE. Its like a custom kind of weird LLM chat and popup windows weird IDE kind of "thing".
Advantages of this approach is much less brainpower needed looking up APIs to find what I want to use or manually typing all code. This also saves on keystrokes which saves my fingers from overworking and prevents any risk of carpal tunnel and whatnot. It should greatly speed up my coding development compared to manual typing especially once all the features I want the Orchestrator to have are all working.
Note: when a new session starts, I will have a big context dump notify chatgpt of its role and of our plans and short-term and long term goals and keyword trigger commands it can give the Orchestrator to get things rolling and have it go out and find files or directory structures etc from the codebase to help chatgpt navigate the codebase. Together with Chatgpt the Orchestrator will give a context snapshot to catch chatgpt up to date on what the code does so far for the module we are working on, what steps were done recently, what next steps are, etc.
Note: as of right now the way chatgpt talks to the Orchestrator is by me manually copying the browser text output of chatgpt. The Orchestrator polls the mouse clipboard to read these text inputs and parses them and acts on them accordingly. But soon I hope to develop a way for the Orchestrator to scrape the DOM of the browser to read the output of chatgpt directly or create a browser extension that outputs that as a file or as a web socket communication to the Orchestrator or perhaps eventually even have the Orchestrator just use computer vision to literally read the pixels of the screen to read what chatgpt is saying and get its input that way just as my own eyes do. Not sure what direction I'm going to go on that front quite yet but that's coming soon I feel. That will make it even easier to use.
Note: unlike most local AI agents that have to use a local LLM (costs alot to have a good one as far as hardware which is super inflated right now as well in cost) or use a cloud LLM API (charge based on tokens used or a monthly subscription - heavy use gets extremely expensive with guys like Yegge saying they are spending like $3k/mth on tokens WOW!), I chose to just use free Chatgpt as my LLM hookup. And that's good enough. But going that route, not using an API, I can't brute force problems as fast or as parallelized as some AI agents are doing but that is fine because I'm not having AI write my entire program and beat its head against a wall trying to fix its own bugs for ages and work through its own spaghetti code making stupid mistakes but eventually after a million tokens are used it finds its way like a blind man reaching around bumping into stuff in the dark, I don't need big brute forcing like those full automated AI agents are doing. So I don't need massive token use and fast calls, etc. Since I am myself co-coding, reading everything, preventing any bad code changes from making it through into my codebase, I don't need the brute forcing stuff then. And my usage can still fall into normal expected use category and not get rate limited or get me banned. I'm still the only one interacting with my mouse and keyboard into chatgpt. All inputs are manually done by a human user. So yeah, with my system, the LLM co-piloting is FREE which is important for me on my tight budget.
So anyways, chatgpt and I developed this system of using this Orchestrator as a 3rd copilot. Chatgpt is my copilot and the Orchestrator is our 3rd copilot. The Orchestrator extends Chatgpt's abilities to leave the browser and do stuff online or with my file system etc as its assistant just like local AI agents do. So it is loosely inspired by the same concept as a local AI agent. I am excited about this tool/workflow. I think it will vastly speed up my overall developer speed while still giving me fine grained control. So the downsides of automated code production associated with vibecoding don't really apply here since I'm not taking myself out of the loop so much like people warn about.
So to make this Orchestrator, chatgpt highly recommended we use Python. I've never coded in Python before and was under the impression its much slower than C/C++ so no good for anything in my robotics projects. However, since this is basically just a sort of weird LLM assisted coding assistant thing we are making, I figured it's probably fine for that use case. So I gave in and downloaded an old version Python that runs on my machine. Within a few days I, with chatgpt's help, got Python installed and working and learned how to use a text file as my Python code which I edit in notepad on windows. I use a .bat file to launch that orchestrator.py file and it launches and works. We've got it polling the clipboard and taking action when valid clipboard changes come in, doing some simple things chatgpt tells it to do successfully. I am also working on implementing a boot sequence thing where chatgpt commands it to run a boot sequence which has it open a window where it asks me to select what coding project I want to work on today from a list we store in a txt file and I press a letter on my keyboard to select a coding project from that list. It then pulls up a .txt context file about that coding project from the Orchestrator directory containing these project specific context files and it puts that file plus a list of trigger keywords and instructions chatgpt can use into the mouse clipboard and tells me to paste in the context. I then paste that in and chatgpt is told to basically use a series of command trigger words and commands to essentially open up my codebase of that particular coding project, explore the files, explore the directory, explore the various sections of code, and find out where we left off and see what the next steps are on the coding to do list for that project if any. If none, it will work with me to create the next steps of a todo list for that code project. We then can start to code it.
So far the orchestrator.py is about 500 lines of Python code. It's all bug free and working great. I took the time to carefully read it all and understand it all and now carefully read and understand every proposed change chatgpt writes for it. Only then do I add it and test it. But eventually, my aim is to have the Orchestrator do the reading of the original code and the proposed changes or additions and validate and filter it before I personally read and approve change or addition requests. The idea there is that my brainpower is limited and I only have so much fuel in the tank mentally for a given session. So the Orchestrator will see if chatgpt is doing something clearly dumb in its code change or addition request and catch that and have me paste the problem back to chatgpt by just bringing a popup window saying "paste this to chatgpt" and I just paste it. No thinking needed. And chatgpt corrects itself and tries again. Only once Orchestrator approves do I get a popup window showing the code change and old code and highlighted changes or updates text for me to read carefully and approve or reject. By taking my brain out of the loop for the dumb mistakes, the Orchestrator shields me from petty code corrections mostly and filters out the obvious dumb LLM mistakes so I don't have to. This saves me frustration and brainpower so I only see the good stuff that makes it through the filter. That makes the system more friction-less and leaves less waste of my time nonsense to deal with so I don't get so frustrated with dumb LLM code outputs. And the idea to possibly send it off to Gemini or w/e with their API free tier usage to verify it if it was a complicated change the Orchestrator wants a second opinion on should be icing on the cake and all of this happens behind the scenes while I wait.
I will say this: for me to get as far as I did with the Orchestrator in just a few days as I did is a marvel for me. I am not that fast but with Chatgpt's guidance I am so much faster. I found a 5.5 hour tutorial on how to install Python, get it going in a IDE, create projects, etc etc and watched some of it and realized I didn't need to do any of that. Chatgpt had me up and running Python in under an hour as someone who never even used it before and we were already having working code within the hour. It was amazing. Super fast for me. Chatgpt still makes dumb mistakes and bad code often, but with the Orchestrator and its guardrails and a tightly designed context window and guidance, plus all the filtration and validation steps, this can be a amazing semi-automated coding workflow.
So that's where I'm at. It's exciting stuff. This doesn't mean I'm stopping the electronics development. I plan to do this stuff in parallel with that so updates will still come on that. But the whole wait to code AT ALL until all electronics are done I just could not stick to anymore. It's been like 3-4 years since I last worked on coding for the robot project and I just couldn't hold off anymore. I think coding some then working on electronics some then coding some is fine. A bit all over the place but so be it. I got caught up in the AI assisted coding hype and just couldn't help myself jumping in and figuring out how I can best use AI to help my coding adventures in a way that fits my needs best. I couldn't wait anymore. PLUS, if I spend many more years NOT coding, I'd start to get somewhat concerned that what I already coded and learned and still remember would start to fade more and more from memory and I'd basically have no clue of what I was trying to do if I wait too long. I wanted to get back into my code before I have no mental architecture skeleton left in memory which would make things harder for me to get back into it. It's a lot of things to keep in my mind for so long without actively spending time in the codebase. So yeah that's my other excuse for why I'm going back into it "prematurely."
Note: my first impressions of Python were very, very good. I was amazed at how much it achieved by so little lines of code. Its 500 lines of code it has so far would have taken like 3,000 lines of C/C++ code I feel. It is crazy. It's very intuitive to use. I already just get it. Although chatgpt is doing the heavy lifting so I'm not actually typing it out myself. But it doesn't matter as long as I understand what it's all doing and how then I can keep its architecture clear and consistent and avoid bugs.
-
Ok so I created what I'm calling the Orchestrator.py, a python code a couple thousand lines long that interfaces with chatgpt, being able to go into my codebase for chatgpt and pull sections of code out and populate my clipboard with that code and ask me to paste it in for chatgpt which I then manually do. Chatgpt outputs commands like list all sections of code in this or that file and if I copy this command, the orchestrator who polls the clipboard goes out and goes into the code file and parses out the code section names and populates the clipboard with it and tells me to paste it in to chatgpt which I then do and then chatgpt is like okay, these 3 code sections we are dealing with for today's project, pull out code section #1 - lists its name and I copy this request into clipboard and orchestrator goes out and pulls that section of code from the codebase, populates it into the clipboard, and tells me to paste this into chatgpt which I manually do. So then chatgpt fully is able to get up to date on the codebase and where we left off. Also backing up a bit, this ALL starts off for a new session in chatgpt with me pasting in a huge context dump about my various projects and the orchestrator.py and the commands it can give the orchestrator.py etc and kind of seeding its context window with what is going on. Then it begins issuing the commands to list sections of code or w/e. Next I have to manually launch the orchestrator.bin file which launches the python code of orchestrator.py which upon opening asks me what code project we are working on this session and gives a window with a list of coding projects we have ongoing. I select from that list the coding project we are doing that session. The orchestrator then takes the coding project I selected and opens up a context txt for that coding project that lists the overall goals of that project, the list of to-dos for it, the most recently completed steps, and where we left off, any constraints, any special notes or rules, any dependencies, any special files or directories the related project files are located in, etc etc. It copies this coding project specific txt extra information into the clipboard and tells me to paste that into chatgpt which I then do manually. So this way chatgpt now has overarching major context dump for all coding projects and then today's coding project specifics for that session. It is now fully equipped to be my coding copilot. The orchestrator saved me just a ton of navigating codebases and files and copy pasting all the time. That is basically its job, to be a bridge for chatgpt and I into the hard drive and the projects. My next plan for making this even more seamless that I have been working on is to make my own diy browser. This browser will then be my interface for chatgpt and will enable my orchestrator.py to tap into what chatgpt is saying to me without me having to copy output text from chatgpt into my clipboard for the orchestrator to see the output of chatgpt. The browser will communicate this output text via some method that the orchestrator.py can read. Haven't decided yet how. I think socket based client server communications tunnel is the normal way two separate programs communicate like this. Although I could just output to a txt file maybe? I have used just changing the title of a window's text as a way to have two programs talk to eachother. Sometimes high speed talking can be too laggy or buggy when talking via .txt file generation and deleting. But there might be workarounds for that. And it depends on rate of communication needs too I think as far as when bugginess kicks in.
So anyways, as far as the diy browser goes, so far it creates a socket, uses OpenSSL, creates the handshake, connects to a web server, creates get requests, downloads that request, parses some of that request, etc. So I've come a long way with it. My first server I'm teaching it to connect to is gmail. So far it will connect to gmail.com and get a 301 redirect to https://mail.google.com/mail > it detects this and it then redirects to that url. That URL then issues a 302 redirect telling the browser to go to https://accounts.google.com/ServiceLogin?service=mail which is the login page for google accounts. That is where I paused for now. So it now needs to detect that 302 redirect request and close the socket and close the secure connection handshake stuff and start a fresh socket and fresh secure connection and connect securely to the account login page.
I chose gmail as a test bed starting point for the browser since one of the things I want the browser to do is act as a very advanced spam filter but more. I want it to actually go into my spam folder and follow custom rules to locate certain specific types of spam and delete it out of the spam filter folder for me. Then when I regularly look through my spam folder for anything that is not spam, I won't have as much regular and obvious complete junk mail in there to sift through to find non-spam. I know you can use a couple popular 3rd party software to interface with browsers with your desktop applications like Selenium and Puppeteer but I prefer not to get locked into any 3rd party ecosystem for this kind of thing and want to DIY this instead for MANY reasons I won't go into here. Suffice to say I've wanted a DIY browser for browser related personal AI assistant related tasks like the spam filter filter of filters thingy I was talking about before as well as many other cool projects related to browser automation and I've wanted to do it from the ground up for years for many reasons. One of which is I simply want a custom browser in GENERAL even for personal use. For various reasons I want this to supplement Chrome and Firefox and Opera and Vivaldi and Supermium etc that I use already for various things.
So anyways building your own browser is a huge job but I think its a great asset for my goals. It will play a key role in my AI for my robot being able to use the internet to do many many things like researching, learning, watching videos, training, etc. I plan to have it be a very minimal diy browser that does bare minimum html parsing and display as well as parsing and displaying Javascript to a smaller degree. It won't be a full JavaScript engine it will just do bear minimum to get the key dynamically loaded content downloaded. I do not even intend for it to display websites as they were intended to be displayed by the website developers. It will just display websites as pure text with most images removed in many cases and it will often run in headless mode which means no graphical interface at all just console outputs only in many cases. It will often be moreso just a bridge between my AI and websites than a proper actual browser that people use with their mouse and keyboard to interface with websites as a human user of websites. But it WILL enable that form of use of the internet and websites as well as a optional use of this browser. So it will be multipurpose. One thing I want for it to be able to do one day is lets say the robot is fixing one of its own pulley systems and notices the ball bearings for pulley system repair are running low on stock. It can go online and order more ball bearings and doesn't even need to ask me first. It would just use my credit card and buy it. And one day ideally it would make its own money online and use its own money to repair itself so it doesn't use my money. I'd let it have its own money for its own maintenance and business ideas although the latter would be limited and need some oversight but could be a cool realm of experimentation that could be fun. So yeah, that is just one of like thousands of potential future uses for it.
Well and since I said this much I'll say a LITTLE more my philosophy and approach behind this custom browser thing. Because I plan to run windows 7 on the robot and use it myself, refusing to upgrade to Windows 10 and GOD FORBID the notoriously and INFAMOUSLY Windows 12 NIGHTMARE that is causing mass exodus of faithful Windows users to Linux in recent times, that really affects my long term planning. By choosing to stay in Windows 7, now all browsers are going out of support and websites one by one are no longer displaying saying I must upgrade my browser. Soon extensions will stop working and all things will start to be unusable one day. So by making my own Windows 7 friendly browser now, I don't EVER have to worry about losing the ability to use Windows 7 as my daily driver. Supermium browser is a legacy windows friendly browser that IS maintained and still works on all websites but is that guaranteed to be maintained 15 or 30 years from now? Not in my opinion. Better to just roll my own now if I plan to stay on Windows 7 forever. My next operating system upgrade may never come or may be Linux or may be my own custom operating system which I already started building. But in the meantime a bare bones custom browser will potentially turn into a great thing for me.
Now alot of the diy web browser progress I mentioned here I did the work on like 4 years ago I think and there's video footage on my youtube of me making it on my youtube channel. I was just continuing where I left off on this project recently is all. Did not get a ton done yet recently but did progress a bit. And I'm HOPING that with chatgpt and the orchestrator.py's help that I can code much faster now on the DIY browser development. We'll see. I think I do code a bit faster with it so far but I am still hoping to improve there.
As far as the robot electronics, I did manage to find my hotplate with temperature control knob and a nice glass vessel I can put on the hotplate with water filling it up half way that I can heat up to 110F or w/e the ideal is for the etching solution I'm using. Then I will put the plastic earplug container I used for etching the little PCBs inside that hot water and do the etching at these higher temps. So I have everything ready for that next step. I did not start making the motorized etchant agitator yet though.
-
I got together my temperature sensor and my hot plate and my glass container and some water and figured out where on the hotplate temp dial I need to be to get the desired water temperature. I then used label paper sticker and marked it off and wrote 118f on it which is the average temperature of that spot on the dial. It has about 15 degrees variance I think up or down. Good enough.
Next, I mixed up a batch of water and PCB etchant (Ammonium Persulfate crystals and water mixture) using a postal scale to get the ratios right. I mixed it into the bottom third of a wet ones baby wipes container. It was 0.8oz total. Then I submerged the etchant mix into the warm glass basin of heated water to bring it up to temp. I noticed the etchant wet ones container wanted to tip over so I used scotch tape to tape it off in all 4 directions to the glass container and pull it under water a bit too in order to maximize temperature transfer from the hotter outside water into the etchant container contents to warm it efficiently. I skipped the automated agitator entirely opting to just stir the mix with a hot glue stick manually.
(https://github.com/artbyrobot/realistic-humanoid-robots/blob/main/temperature-controlled-circuit-board-etching-setup.jpeg?raw=true)
All in all, it did etch within the 5 to 8 minutes range and I think etched even faster when the temperature was closer to 130f - closer to 5 minutes then maybe even 4 minutes I didn't time it. It was lightning fast compared to room temperature etchant which took 2-3 hours to etch a single board. So indeed, the instructions that said room temperature is fine were wrong. All that leads to is undercutting.
Anyways, with the stirring and the warm temps my results were significantly improved and almost every board was usable. I produced 8 or 9 in total. Enough to do at least 2 motors and part of a 3rd at least. So plenty for now. I had still a tiny bit of undercutting on the fine traces, but rarely enough to break their continuity. I will make the traces slightly wider in Photoshop for future prints with the expectation that around 15% of the outer edges will be removed so we print wider to compensate and then the result will be the width we wanted in the first place after the undercutting has done its thing. This way the undercutting is worked with and non-detrimental. That's my planned workaround for it.
(https://github.com/artbyrobot/realistic-humanoid-robots/blob/main/etched-circuits.jpg?raw=true)
In the rare instance of pinholes randomly in the center of pads or traces or a tiny open circuit on a thin trace, I am confident that a coating of solder over all of those areas will correct that. These little holes and whatnot are microscopically small so very easy to solder bridge as needed. I think for the most part my boards are almost all fully usable as is. I'm sure my methods will improve as I continue to tweak and iterate techniques over time - but the fact that we can already produce working circuits at this extremely fine detail and miniaturization level is already very encouraging. Any improvements from here is just icing on the cake IMO.
My next step will be to solder on the half bridge IC chips using the method shown in this video - a method I think looks very impressive and sound and hopefully not too hard to replicate on my end: https://www.youtube.com/shorts/r-HaRjBvWgU
-
Here's the center cutout now which was the last thing I needed to do before soldering down the chip. This access window will enable me to solder the main power lines to the main pads on the bottom of the chip. The circuitboard is aimed at tying into the various perimeter pins of the chip but this window is for the high power lines on a separate layer below.
(https://github.com/artbyrobot/realistic-humanoid-robots/blob/main/center-cutout-of-half-bridge-circuitboard.jpg?raw=true)
I was able to cut this window out with the highest zoom setting of my magnifier visor (I think like 20x zoom?) and an exacto knife. Quite a challenge but made it happen!
-
So as I fast approach motor controller wiring phase, I figured I would revisit placement again. Upon further reflection I decided hovering midair motor controllers attached to nothing might not work as they'd perhaps be a bit in the way of getting at the motors and just be a bit overwhelming. I'm not positive on this and could revisit the concept but for now I'm thinking of just mounting it side saddle onto the motor again. I decided to place them side by side with inlets on the output shaft end and outlets on the BLDC motor wiring's end. I drew this sketch of the layout and wire flow as a visualization aid.
(https://github.com/artbyrobot/realistic-humanoid-robots/blob/main/new-motor-controller-wiring-and-placement-concept.jpg?raw=true)
-
Ok I used the tip of my exacto knife to carefully scoop on low temp solder paste and then carefully drag soldered it over the key areas I wanted pre-tinned. There do not appear to be any short circuits and the amount of solder on each pad and trace seems a decent amount to me. I forgot to wipe it with alcohol wipe but have done so since taking this snapshot.
(https://github.com/artbyrobot/realistic-humanoid-robots/blob/main/pre-tinned-flat-flex-pcb.jpeg?raw=true)
The next step is I have to carefully uv cure solder mask that little trace runs under the IC chip. It definitely will short a pad to something I think if I don't. I have to apply it very thinly so it doesn't prevent IC chip from seating flat and soldering into place well.
-
So the plan I have for the heat sinking main conductors that attach to the bottom pads of the IC chip I decided to draw up to explain it. It will be in layers. First you have the chip on the bottom facing bottom side up so the pads are exposed upwards. Then on the first attachment layer I cut out matching shaped copper plates from copper sheeting and solder that down with low temp solder paste and a soldering iron. In theory, this first layer attachment will basically just be extending the pads up past the viewing window of the DIY PCB with cutout viewing window we've made so far so that the DIY PCB we made so far and this first layer of copper plates together act as layer 1. Ideally the copper plates would be slightly proud of the printed PCB in height I think. This first layer copper plates that we are soldering onto the pads of the IC carries the current and the heat sinking to layer 2 without the need for vias. In a multi-layer PCB made industrially, vias would take the heat sinking and current to layer 2 of the board and we are just using solid copper plates instead which should be even better than vias because its solid copper instead of just via holes so more surface area than vias would offer. Now on layer 2 we can create a much larger sheet that extends out past the PCB way off the chip and that portion that extends way off the chip acts as a tab we can solder the V- wire to. It also acts as a tab we can solder our 6 strands of solder wick wire that act as heatsink fins to. Layer 2 also has a plate that brings the V+ to layer 3. For layer 3 we just attach a large sheet of copper which also extends way out past the chip and acts as a tab we can solder our V+ wire to and our heatsink solder wick wires to.
(https://github.com/artbyrobot/realistic-humanoid-robots/blob/main/copper-cooling-plates-layering-idea.jpg?raw=true)
-
Ok so the Relife RL-UVH902 UV fast cure solder mask order has arrived and so has my order for a Relife UV curing light to cure the solder mask quickly and effectively. So now I just need to solder mask off that little trace that goes under the half bridge IC chip.
(https://github.com/artbyrobot/realistic-humanoid-robots/blob/main/uv-curing-light-for-solder-mask.jpg?raw=true)
(https://github.com/artbyrobot/realistic-humanoid-robots/blob/main/uv-fast-cure-solder-mask.jpg?raw=true)
-
Ok I managed to apply the UV solder mask today and it seems like it worked quite smoothly. I used the tip of a small sewing needle to spread it over the trace and then held the UV light on it for 10 seconds to play it safe. I used transparent UV solder mask so you can still see the trace but its a bit more murky/cloudy when you see it. I used the tip of an exacto knife to put little scratches on the UV solder mask to test its thickness by feel and test its durability a bit to scratching. And ensure it was fully cured. It was very hard and durable and seems to have gone on fairly thin. The question is, is it too thick/proud of the surface for the soldering on of the chip over it? This is the million dollar question. Because if the mask lifts the chip up off the PCB even a tiny bit then the soldering may not reach between pads on the IC and pads on the PCB, failing to bridge the distance. That is my main concern. If I have any issues with that, I will have to reroute this trace to go around everything rather than on the shortest path like it is now. The shortest path leads it under the IC and led me to have to mask it. Extra steps like this are a bit annoying. I kind of wish I just routed it around everything out of the way more. Then I would not need to UV solder mask at all. Perhaps in a future board iteration I will do this improvement but we'll see. For now I made several boards and want to stick to them since it would be more work to remake them all.
(https://github.com/artbyrobot/realistic-humanoid-robots/blob/main/uv-solder-mask-completed.jpg?raw=true)