Thread 2955898

Last Threads: https://warosu.org/diy/?task=search2&search_username=artbyrobot


To begin: the project goal: I am working to make a series of humanoid robots. I am using a Biblical theme of naming the first 3 robots I make Adam, Eve, and Abel. The goal is for these robots to have human body inspired musculoskeletal systems, advanced AI, and that they look human and pass for human to a casual observer at least at a distance. They must be able to walk, talk, run, dance, do sports, do chores, manufacture products, and make more robots just like themselves if not even better. My aim is to build a single robot arm and head and then add sufficiently advanced AI to that arm and head to enable it to build the rest of its own body for me. This way I am delegating the work of building the majority of my first humanoid robot to that robot rather than doing that work myself - and this is to save me time.

In a like manner, my goal with the AI is to code just enough AI that the AI can begin coding itself and this way I don't have to code most of the AI myself because it will self create itself. I liken this to building a seed and that seed growing into a tree because for me to code that tree would take too long for me and just creating the seed would then save me time.

I find it kinda funny that there's a lot of control algorithms and methods and optimization techniques that got some really weird names, like "Bang-bang function parameter optimization" and "Hummingbird optimization" even though the only the thing they do is just to figure out which curve from a family of curves best fits a certain set of constraints, which can then be used to keep something really dull and gay like an industrial liquid solution at a certain ratio. The brightest minds in Control Engineering are literally just designing techniques and setting up simulations for shit that sounds like it should be tried and true by now, like optimizing the number of Syrian and Palestinian children killed by dropping a bomb from a certain height.

Meanwhile OP might not know that much about MATLAB or other fancy math scripting langs like that, but at least he got good intentions and wants to make something that looks good.

imagine actually creating an ai capable of self refinement and instead of allowing it to solve lifes greatest problems and/or trigger the start of a technological singularity but instead work on whatever retarded shit this is

>>2955929
life's greatest problem is that most of creation has rebeled against it's creator. Sin has entered the world. Light has also entered the world but men hated the light because their deeds were evil. My robot will Bible thump at sinners most of the time which will hopefully make them repent and feel great shame. That solves in a small way the world's greatest problem by order of importance.

>>2955898 (OP)
Hey man. I rarely check in on your threads to see how your bot is coming along.
Any real progress? Do you have the body fully assembled? Are you just working on software? What's the deets, my dude?

>>2955998
I only have the skeleton of the arm assembled and a single motor attached to that and a single tested downgearing iterations attached to that and those attached to a single finger joint. I am now developing the custom bldc motor controller. I already finished the schematic and am building the physical implementation. I am figuring out miniaturization, heat sinking, EMI concerns, major bus pathing, test points, insulation, where flat flex custom pcbs can be incorporated to streamline production, how to support fragile wire connections with strain relief, etc. There's a million things I have to consider for every part I put in. Its extremely complicated and slow going with a ton of research and planning going into it.

>>2955998
>Are you just working on software?
No. I am unimginably hyped about working on the software like a kid wanting to open xmas gifts but am disciplining myself not to do it until the hardware is in place. Then the software will have a form to embody and control and interact with the real world by way of that. I feel the skeleton should come first then the mechanical/electrical engineering and THEN the AI as the final step. As soon as the arm and a minimum viable head (just eyes for now) are done I'll swap full focus to the AI dev. Not until hen.

>>2956003
>>2956008
Nice nice. You're cpming along nicely! Got it all planned out, aye? I hope you continue to work on it! Can't wait to see a final product one day.

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.

Here is my updated schematic:

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.

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.

>>2956056
My brother in Christ, you should definitely use KiCAD or some other schematic-making program if you're gonna have to keep track of every single component you're gonna have to wire literally from head to toes.
Also, you might wanna consider implementing a distributed control system with one "master" controller and several "slave" controllers (y'know, the way the human brain has to communicate with neurons all throughout the body) so as have, say, one controller controlling all the fingers and joints in one hand or all the toes in one foot, but to also have them all synchronized so as to cooperate on actions that require several limbs, such as walking through a path with lots of obstacles, wrapping presents, or washing dishes.

>>2956062

>just use KiCAD
well I did as shown here: https://youtu.be/pE9f_bEhd4o

but I don't like it and would only use it if trying to get PCBA again which I currently plan to never do again. I prefer photoshop and handmaking circuits.

>use distributed control system

I plan to. There will be a main brains PC - a mini ITX gaming pc, then that will feed into a master arduino mega 2560 pro mini which will feed into many lower tier master arduino mega 2560 pro minis to do the lower level grunt work.

I ought to design a small non-human robot, but I have nothing I need automated cause I do everything myself.

>>2956089
how many watts of power will be used for processing?
how many for movement?

>>2956129
alot and not practical to estimate IMO at this time

>>2956158
not even ballpark?
seems pretty important to budget power requirements

>>2956179
For my humanoid robot I’ve got about 300 motors total, but for a high-strain activity like a deadlift, only a subset is under peak load. The legs, glutes, and back use the 10 big 4082 motors, the torso/back uses 25 mid-size 2838/3650 motors, and about 70 small 2430 motors handle arms and fingers at holding or assisting load.

Starting with the small 2430s, each is rated 200W at 7.4V and 20A. I’m assuming 60% of rated power for this deadlift scenario. So per motor:

200W × 0.6 = 120W

With 70 motors:

120W × 70 = 8,400W ≈ 8.4kW

For the 25 mid-size 2838/3650 motors, rated around 500W each, I’m assuming 80% load:

500W × 0.8 = 400W per motor

25 × 400W = 10,000W = 10kW

For the 10 big 4082 motors, rated ~2,300W at working voltage, I’m assuming 90% load:

2,300W × 0.9 = 2,070W per motor

10 × 2,070W = 20,700W ≈ 20.7kW

Adding them together gives the instantaneous power draw for the deadlift:

8,400 + 10,000 + 20,700 = 39,100W ≈ 39.1kW

For batteries, I’m using 500 Sony VTC6 cells (150 on-body, 350 in backpack). Each cell is nominally 3.7V, 30A short-pulse (5s). 500 x 30 x 3.7a = 55,500W ≈ 55.5kW

We are then using 39kw of a possible 55kw to perform the deadlift leaving a 16kw buffer.

Sequencing the motors realistically allows full-body high-strain movements like a deadlift without exceeding battery limits,

Electronics / PCs Processing

Arduinos, gate drivers, sensors: ~150–200W — trivial compared to motors.

Mini-ITX gaming PC in torso + high-end humanoid PC in head: ~500–1,000W total — still small relative to motors under high-strain