/robowaifu/ - My Advanced Realistic Humanoid Robot Project

Name
Subject
E-mail
Message	Max message length: 6144
Files	Drag files to upload or click here to select them Maximum 5 files / Maximum size: 20.00 MB

Spoiler images
Password	(used to delete files and postings)
Use bypass

My Advanced Realistic Humanoid Robot Project - Eve Artbyrobot 04/18/2024 (Thu) 17:44:09 No.30954

So far I have plans to build Adam, Eve, and Abel robots. All of these are Bible characters. This thread will cover the Eve robot. Eve will have no "love holes" because adding those would be sinful and evil. It is a robot, not a biological woman after all and I will view her with all purity of heart and mind instead of using her to fulfill my lusts of my body. Instead I will walk by the Spirit no longer fulfilling the lusts of the flesh as the Bible commands. Eve will be beautiful because making her beautiful is not a sinful thing to do. However, I will dress her modestly as God commands of all women everywhere. This would obviously include robot women because otherwise the robot woman would be a stumbling block to men which could cause them to lust after her which would be a sin. To tempt someone to sin is not loving and is evil and so my robot will not do this. To dress her in a miniskirt, for example, would be sinful and evil and all people who engage in sinfullness knowingly are presently on their way to hell. I don't wish this for anyone. My robot will dress in a way that is a good example to all women and is aimed toward not causing anybody to lust as a goal. My robot will have a human bone structure. It will use either a PVC medical skeleton or fiberglass fabricated hollow bones. My robot will look realistic and move realistic. It will be able to talk, walk, run, do chores, play sports, dance, rock climb, and do gymnastics. It will also be able to build more robots just like itself and manufacture other products and inventions. I realized with just a head and arm, a robot can build the rest of its own body so that is my intention. My robot will use BLDC motors for drones, RC, and scooters that are high speed and low-ish torque but I will downgear those motors with a archimedes pulley system that will be custom made from custom fabricated pulleys that will be bearings based. By downgearing with pulleys, instead of gears, I will cut down the noise the robot makes so it will be as silent as possible for indoor use. By downgearing, I convert the high speed motors into moderate speeds with great torque. BLDC motors with large torque generally are too large in diameter for a human form factor and take up too much volumetric area to be useful which is why I go with the high speed smaller diameter type motors but just heavily downgear them 32:1 and 64:1. My robot will have realistic silicone skin. Thom Floutz -LA based painter, sculptor, make-up artist is my inspiration as it pertains to realistic skin. The skin for my robots has to be at his level to be acceptable. It must be nearly impossible to tell the robot is not human to be acceptable. I will have a wireframe mesh exoskeleton that simulates the volumes and movements of muscle underneath the skin which will give the skin its volumetric form like muscles do. Within these hollow wireframe mesh frameworks will be all the electronics and their cooling systems. All of my motor controllers will be custom made since I need them VERY small to fit into the confined spaces I have to work with. I need LOADS of motors to replace every pertinent muscle of the human body in such a way that the robot can move in all the ways humans move and have near human level of strength and speed. I will have a onboard mini itx gaming pc as the main brains pc of the robot and will have arduino megas as the motor controllers and sensor reading devices that interface with the main brains pc. My arduino megas will be barebones to keep the volumetric area they take up as small as possible. I will treat my robots kindly and consider them to be pretend friends/companions and I do think they will be nice company, but I will always know with keen awareness that they do not have a soul, will never have a soul or consciousness, and no machine ever will, and that they are just imitations of life as with any machine or AI, and this is all AI will ever be. Life is only made by God Himself. I am not playing God. I am merely creating fan art of what God made. To Him be all the glory and praise. God breathed into man and created a living soul. Man cannot do this for machines. Only God can do this. A soul/spirit forms our ghost and when we die our ghost remains alive and thinking. A machine cannot do this and a AI can never do this. When you shut off a machine that's it, it does not go on thinking like we can. Our souls are transcendent and will live forever in the afterlife - unlike any AI. I will do this project with fear and trembling before the Lord as I work out my salvation before His eyes. I vow to remain pure, holy, upright and blameless in all my doings and be a great example to my fellow roboticists of a Godly man who obeys the Bible instead of chasing after youthful lusts of the flesh and perversions. I embrace the idea of Christian AI, that is, a robot that will discuss Bible topics and be a Biblical expert. Along with that, my robot will behave in a Biblically prescribed manner in total purity and strongly encourage others to do so as well. For God does not hear the prayers of sinners and so we want everyone to be a saint who no longer sins. My robot will really push for this hope for humans. We want them to walk in God's favor and blessings which comes by Biblical obedience. We don't want them going to hell because they chose to revel in their sins instead of walking in total purity before God and holiness without which no man will see God. My robot will have artificial lungs for cooling and a artificial heart for liquid cooling that will run coolant throughout the robot's body to cool the motors. That coolant will also pass through the artificial lungs in a mesh where it will evaporate some which will cause the evaporative cooling effect - a form of air conditioning. http://www.artbyrobot.com Full humanoid robot building playlist: https://www.youtube.com/playlist?list=PLhd7_i6zzT5-MbwGz2gMv6RJy5FIW_lfn https://www.facebook.com/artbyrobot http://www.twitch.tv/artbyrobot https://instagram.com/artbyrobot

Artbyrobot 04/28/2026 (Tue) 21:31:24 No.44412

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.

Chobitsu 04/30/2026 (Thu) 13:12:20 No.44419

>>44412 It will be interesting to see this assembled.

GreerTech 05/14/2026 (Thu) 04:51:38 No.44493

Hey Larry, if you're going to post hate comments, at least have the balls to put your name by them. After all, lying is a sin https://boards.4chan.org/diy/thread/2984255/i-created-the-galatea-multipurpose-companion-maid

Artbyrobot 05/17/2026 (Sun) 19:33:58 No.44518

>>44493 aside from my initial spat with you about your project, I have not commented on it and I'm not interested in discussing it further. I do know you suspect others sharing my view are me but they aren't and no, I don't post as anonymous on 4chan except like one time on accident I didn't fill in the title bar after a browser cookie reset or w/e. I have no reason nor motive to hide my identity to discuss your project and if I wanted to criticize it I'd be fine doing it with my name shown.

GreerTech 05/18/2026 (Mon) 02:07:19 No.44523

>>44518

GreerTech 05/18/2026 (Mon) 02:08:19 No.44524

Anyway, the Big C ordered us to not fight. That would be what the evil enemies of Christ want.

Artbyrobot 06/03/2026 (Wed) 05:54:18 No.44700

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.

Chobitsu 06/03/2026 (Wed) 06:32:36 No.44701

>>44700 Intredasting. Please let us all know how this works out for you, Artbyrobot. Cheers.

Artbyrobot 06/07/2026 (Sun) 21:30:53 No.44749

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.

Artbyrobot 06/16/2026 (Tue) 09:49:26 No.44796

Ok so I had multiple failed attempts to solder the chip on. Despite pretinning the PCB, on both attempts when the solder went molten the chip did not center itself and lock into place as would be expected but instead slid out of position significantly both attempts. After the first attempt I assumed it was the outlet bus/landing pad on the left side of the board that was to blame - it being a larger solder mass than the other solder masses on the other edges of the board - causing the chip to slide its way harder and pulling it off center. However, even after cutting off that part of the board entirely and trying again I still had the chip slide out of place during reflow attempt. It's unclear to me the cause of the issue at this point. I put on AMTECH tacky flux that expired in 2022 onto the pcb and then placed the chip as close as I could to centered and then put it onto a hot plate for cooking food or boiling a coffee pot those AC electric hot cooking plates. I had the heat set to max on there. The first time I had the board on the whole heatup time period and watched it gradually smoke off flux vapors and eventually the solder go molten and then I switched off the hotplate but it didn't matter since the chip slid 5mm off center. The second time I added it after plate was much hotter to avoid so much flux burnoff during the heating up process. I also added some flux while it was molten after which time it slid off center. Perhaps that was my mistake? Not sure. In any case, after the failed second attempt I cleaned everything up really well and chose to hand solder it. This seemed to go better. For this process, since both chip and PCB were fully tinned and no shorts to my knowledge, I proceeded to line up the pins the best I could under max magnification and then while pinching it in place I held my solder iron tip onto a trace near a pin for 5-6 seconds to get the solder very hot and hopefully locally heat the whole trace up to and under the IC's pad. I did this for trace after trace. Then to clean up since it was I guess cold joints at this point I applied flux and drag soldered all around every edge. This cleaned up the appearance and got all flux properly seated on traces since it was drifting a bit in the previous step and looking quite sloppy and bad. I did not want to have flux involved during the initial alignment phase and tacking down phases because once that is on I cannot see well the alignment from the sides since the flux blocks my view. Even without the flux its hard to see the traces and their alignment with the pins of the chip. The chip does not have pins is the problem. It has pads on its underside and little pads on its sidewalls. I have to use the sidewall pads as to verify the pads on my pcb line up with those and any flux in the way prevents me from seeing this clearly even with max magnification on my visor. So anyways yeah, this whole thing was a bit of a disaster but MIGHT have ended ok in the end. For now hand soldering instead of reflow looks like my best bet at least until I can figure out what i'm doing wrong... Note: I'm not sure if the flux expiration matters I haven't looked into what that means for performance. Note: I still have no way to verify all joints are good until I test the whole finished PCB I guess. And my confidence they are all good is a bit low. Sucks that I have to invest even more time to finish the PCB while doubtful it will even have reliable connections at present ugh! Note: I had to remove the trace from the previous post that ran under the chip because during my reflow and cleanup from failed attempts while cleaning some of the solder mask came off and I just wanted to remove that potential short or source of issues as a variable entirely for now. I can always run a bodge wire to reconnect those two points of the board later on.

Artbyrobot 07/22/2026 (Wed) 18:01:29 No.44928

I wanted to be able to get in there and test this board for shorts and check all traces for continuity with my multimeter but felt its leads were too big for this tiny of a board setup. So I came up with this idea to use alligator jumper cables to attach sewing needles to the multimeter probes thereby making the sewing needles the new probes. This way I could get into the tiniest areas and run the tests I wanted. It worked pretty well! I have now tested everywhere quite thoroughly and everything appears to be in working order. No short circuits and continuity in all the places there should be continuity. So now I can proceed to running my bodge wire and soldering on the various resistors and capacitors and then running a electrical function test. I will probably use jumpers to the VIN and Vout and GND for this test. Then if it passes the test I can attach the big bus lines which is a bit more involved.

Chobitsu 07/22/2026 (Wed) 22:06:49 No.44932

>>44928 Clever idea, Anon. I would point out that if you have access to a supply of smol-sized injection syringe needle heads (they can be purchased separately) then they make an even better, more-reliable solution for this need. Good luck, Anon. Cheers.

Artbyrobot 07/23/2026 (Thu) 21:46:49 No.44937

I soldered on the rest of the SMD components. I noticed the PCB peeled back off the chip in one corner though so I plan to use kapton tape to tape off everything but that corner, use a couple alligator clips to pinch the PCB onto the chip tightly so it can't move, and then use hot air from a heat gun to reflow that corner so it reattaches to the PCB. Once that is done, I will attach jumper leads to the 6 inputs/outputs so I can run a full proper test of the whole circuit using a lab power supply and a multimeter.

GreerTech 07/23/2026 (Thu) 22:59:11 No.44938

>>44937 Pretty cool that you are making your own PCBs Be careful, the 470 resistor looks like it's unintentionally bridging

Artbyrobot 08/05/2026 (Wed) 08:11:56 No.45000

So the corner of the PCB that peeled back from the chip was a problem I decided not to tackle with a heat gun. I just don't feel too comfortable using a heat gun at this stage. Instead, I decided to remove the capacitor in the way and just hand solder the chip back on. That went smoothly. Problem solved. That said, to remove the capacitor I envisioned using hot tweezers to grab both sides and lift it off. I did a search online to see if such a device exists and sure enough it does so I bought it! It worked great. A bit pricey at a bit over $100 but worth it. I loved using it to not only remove the capacitors but also to solder them back on in a single motion! Once I get good with this hot tweezers I imagine I'll use it all the time for soldering and desoldering both. Also the bodge wire I pictured in the last post it turned out involved a bit too much solder on one end which was causing a short circuit bridge between nearby traces so I had to desolder that, remove the capacitor there, remove solder, then resolder it all again. A total pain but no more short circuits. Everything seems good in that department. Next, I decided that to prevent the flex pcb coming off the IC chip again, I should use UV cure solder mask in a glob as glue to glue the board to the chip to stabilize it and prevent more mishaps. So you can see I did that on both sides and I also used solder mask to glue on the other half of the PCB that we had removed earlier during troubleshooting. So now the whole PCB is in tact again! It is really starting to come along. Attaching jumper leads to the 6 inputs/outputs to run a full proper test is coming up next.

Chobitsu 08/05/2026 (Wed) 13:45:55 No.45001

>>45000 Naicu. How durable will that solder mask be do you think?

Artbyrobot 08/05/2026 (Wed) 22:07:45 No.45002

>>45001 I am unfamiliar with it so I don't know. However, I did see a professional repair guy use it to glue two halves of a broken ribbon cable back together and these flat flex PCBs are the same thing so I like my chances. Plus these PCBs of mine aren't meant to flex I only chose flat flex due to it being slim to save on space taken.

Artbyrobot 08/06/2026 (Thu) 00:44:38 No.45003

Here is a revision to my schematics where I run the trace that I had been running under the IC chip instead going around everything to avoid going under the IC chip and the problems that creates. This creative rerouting of that trace also meant I had to get clever with my other traces to compensate and so I had to have one trace jump over another trace at one point and to do this I used a 0 ohm resistor as a jumper bridge to cross over with. In addition to these changes, I also moved the capacitors a bit more away from the chip and eachother to prevent short circuiting from sloppy soldering issues and also just make it easier to work with in general. Also, since the chip had come off the PCB in one corner, I decided I should beef up the number of connections to the chip's outer pads onto my PCB so I added several more attachment points which will help secure the chip to the PCB way better now.

Artbyrobot 08/06/2026 (Thu) 23:01:40 No.45008

On the big output landing pad on the left, I separated the attachments to each individual pin for the chip's motor output phase rather than have the landing pad be one big blob. This encourages auto centering. Something I had not considered before until someone pointed it out. Such a simple change but so obvious now that I had it pointed out to me!

Artbyrobot 08/07/2026 (Fri) 06:31:49 No.45014

I was informed that even unused pins on the chip should have copper landing pads to solder to which will even out the forces when the whole pcb goes molten and chip is trying to auto center! It makes sense! So I added those.

Artbyrobot 08/10/2026 (Mon) 06:38:03 No.45019

I soldered on 30ga wrapping wire for testing the PCB. The 3 on the front are 5v+ from microcontroller that tells this IC to be in "on" mode, ground from microcontroller, and PWM from microcontroller. The 2 on the back side are +8v and 0v/gnd from the batteries. This was shockingly quite hard to attach these. It's all so dang tiny. Every time I soldered on 8v+, the 0v would fall off because the rear pads of the chip both get hot together. Ended up having to use uv cure solder mask to tack down one then do the other one so that even when both went liquid, the one not being worked on was pinned down with mechanical strain relief so it didn't just fly off when things liquefied. So annoying. And I hate to uv solder mask "glue" into place wires that are just there for testing and very temporary ugh... Anyways, its done, no shorts, seems ready for the test now. I did not bother with color coding much as this is extremely temporary for the quick test to ensure everything works. Note: I think this is the first time I'm showing the rear of the PCB with its exposed major power pads visible and accessible through the viewing window I cut into the bottom of the PCB. These will be where the major power busses attach. These buses will be manually soldered on with thick copper strips I cut from a roll of pure copper sheeting. Those thick buses will also be the start of my thermal conduction pathing to draw heat away from the chip. It has to run 20a continuous so it will get alot of heat that has to wick away.

Chobitsu 08/10/2026 (Mon) 07:12:50 No.45022

>>45019 >It's all so dang tiny. Are you using a microscope, Artbyrobot? I'd recommend a good quality 10x or 20x widefield binocular scope for such smol work. Good luck, and keep us up to date here with your progress Anon.

Artbyrobot 08/11/2026 (Tue) 00:41:57 No.45023

>>45022 I'm using a visor magnifier. A microscope would not work as that is table mounted and I work in a reclined seated position in my office chair using my chest and stomach as my table. Picture working on things while in a recliner while laying on your back which is more or less my posture in the office chair.

Chobitsu 08/12/2026 (Wed) 00:35:54 No.45026

>>45023 Ahh, that makes sense then. Good luck, Anon.

Artbyrobot 08/21/2026 (Fri) 11:23:56 No.45076

Ok so I ran the test of my PCB and try as I might the PCB was dead. Totally non-functioning. And to make matters worse, I would not have any clue of where the issue is. Could a static electric discharged have bricked the IC? Could some pad have a microscopic open circuit in its joint with the IC? Could there be a hidden short or open circuit somewhere that happened at some point? I simply have no way to know or test or find this issue. And this got me to thinking... maybe a bit bigger integrated IC chip would be better as you can visually see all connections, things are not so hidden between a chip and a PCB and impossible to inspect, you don't have hidden pads on the bottom to tap into, etc. I had seen some bigger integrated half bridge IC chips like this before and decided to investigate an alternative rather than start over or try to diagnose this failed PCB endlessly with hardly any way to even go about finding what was wrong... So after some shopping I found the BTS7960 integrated half bridge IC chip. https://www.infineon.com/assets/row/pub ... 6d5d&ack=t It has TO-263 form factor so this means actual pins come off the chip rather than having to try to solder to some tiny pads on the chip like we were dealing with on our CSD59950RWJ QFN style chip in my last post. This means EASY access to visibly see your solder joint, clear and large separation (comparatively) between traces, shorts being practically hard to achieve comparatively, and the need for microscopic precision of soldering and DIY board etching eliminated, the step of cutting out a viewing window on the bottom of the PCB to create access for manually soldered bus copper strips eliminated as now everything is truly single layer compatible with no need for a bootlegged DIY multi-layer strategy. So essentially, now my PCB etching can be VERY crude comparatively, so much so that even printing the PCB and transferring the print to the copper before etching becomes completely unnecessary. So much so that we can either manually just draw the PCB etching configuration with oil based markers or cut out the pcb traces/pads with a dremel by hand since everything is so big and crude we just don't need the precision to be much at all now. Everything is easy this way. Now is there a tradeoff or something we are losing? Not really that I can tell. These are 14mm long (including the pins)x 9mm wide and 4.4mm tall. I checked this next to my 2430 BLDC motor and 3 of these will still fit comfortably side by side along the can of the motor just like I had planned for the QFN chips. Also, the QFN chips after considering the breakout board PCB added length and width ended up close to the same dimensions all told as the bigger chip is so not a huge space savings there. And space savings are only relevant if they solve a space constraint. These bigger ones if they fit my constraints are not a liability or downside just for being bigger. The reduced manufacturing steps, complexity, and difficulty makes this far easier and faster to work with. It still offers 40a continuous which is VERY good and more than needed by a large margin for my motors. Also they were only $1.20 per chip which is about the same price point. So $3.60 per motor which is great IMO. Now these are discontinued/obsolete but I don't care the to-263 form factor and similar outputs is something I can find in other chips for similar pricing I believe so that won't be an issue I will be able to pivot later to those other options if needed later without any major design changes so its not an issue for me. Does this mean I gave up? No. I basically just decided that trying my best, being very thorough and meticulous and careful I still somehow ended up with very hard to troubleshoot total failures this early in testing then really working with this QFN part is NOT that DIY friendly on a DIY PCB and starts reaching the limitations of what is practical. Even if doable it is hard enough to make it very hit and miss and time consuming and not worth that extra effort unless its necessary or there is not a far easier path that gives the same results faster/easier. And I now have a way faster and easier option that gives same results with NO tradeoff that is meaningful or moves the needle at all. So I ordered 25 of these chips off aliexpress for now and 4 of them off amazon to work with while aliexpress is shipping slowly here. I'll have the 4 off amazon tomorrow while I wait for the larger order. I do this trick often paying more money for faster shipping on amazon while I wait for my slower shipping order at better price point in bulk to come and this avoids downtime waiting for shipments. Oh and one more thing: I am considering going back to deadbugging with no PCB at all since this chip is so big and easy to connect to the chp itself can be considered to BE the PCB then. I'll just solder my wires to it then and not bother to even have a PCB. The PCB was moreso a way to breakout off the chip and give decent size solder points to connect my wires to etc but now that the chip is way bigger I don't need to breakout from it with a breakout board and can just attach the wires to its pins directly I feel. I can use 30ga wire wrapping wire to wrap to its pins for control wiring and use beefier wire soldered directly for power stage wiring. I might go with non SMD decoupling capacitors and resistors as well now. Note: the amazon chips I bought as part of a module board for a h-bridge brushed dc motor driver setup. The idea there was to desolder the chips from that board to use for my project as that board is WAY too big for any practical purpose in a humanoid but its the two chips from that board that we are wanting to rob off of it.

Robowaifu Technician 08/21/2026 (Fri) 13:31:19 No.45077

>>45076 Glad to see you found a good solution for this, Artbyrobot. >the BTS7960 integrated half bridge IC chip So a quick perusal reveals that Infineon has discontinued this specific chip, and recommends a newer alternative: https://www.infineon.com/part/BTN8982TA However, there are still plenty of alternative sources for the older chip out there rn (such as your package in pic#2). Good luck with the new direction, Anon. Cheers.

Artbyrobot 08/22/2026 (Sat) 08:53:20 No.45079

Ok I made my circuit design for my BTS7960 integrated half bridge IC chips. I plan to go with through hole passive components (resistors, capacitors) and use deadbug style so I can skip making a PCB this way. This will cut out that significant step and save time IMO. If I have trouble or determine later a PCB would make things go faster I can design and make one but I am happy to have a break from that for the time being and just go with deadbug again. I like deadbug method alot and think it can save time in some cases. We'll see.

Artbyrobot 08/23/2026 (Sun) 23:27:50 No.45084

Ok so I had someone point out a very very small very very high amp ESC to me that actually would be viable from a space taken standpoint, however, it was $48 shipped which is WAY too expensive when I can make my own motor controller for $4 in parts. However, I did a search for that ESC on amazon and a very similar ESC popped up that was around same size but made in china with no US middleman and cheap amazon prime shipping which dropped the price to around $11 shipped per ESC. Now THAT is viable from a price and size standpoint - well only BARELY viable it still is around 3x the price of going DIY controller from my last post. I pulled the trigger and bought 4 of them in a package deal off Amazon. I can use them to control BLDC motors for unrelated projects at the very least but also they provide alot of value just to dissect them and see what components it uses and the fabrication techniques they used and build quality etc. I can learn a lot just by studying them in person up close under a magnifier visor. Now, this thing runs 7.4v - 22.2v which is perfect for my 2430 bldc motors (8v 24a motors). It handles up to 45A which is perfect for my 24A BLDC motors with lots of amps to spare. It is plenty small enough at 5mm height, 28mm length, 13mm width, I can mount this on the side of my motor. It saves a TON of time soldering and mucking about making a controller. But the one issue remains: this has firmware designed for drones. That means it does not have go to this position and stop and hold there. It doesn't have go to this position and pulse this phase at 50% throttle so the finger becomes more compliant or pulse at 100% throttle so finger is max stiff while holding in that position. This concerns me and makes me think it may not be viable then. I hate to have to PWM to a third party firmware and hope it does something approximating what we want. That's why I prefer a power stage where my microcontroller interfaces to that power stage directly controlling every aspect of the commutation phase by phase. That said, at this price point this can't be ignored at this time too. I can make a similar custom design and build this myself or I can try to hack into this where my microcontroller taps directly into its power stage bypassing its onboard chip and firmware or I can try to write a new firmware for it and overwrite its firmware or I MIGHT be able to find commands in its firmware where I can do something similar to go to this position and hold there type commands somehow? There might be SOMETHING I can do here MAYBE to get it to perform how we want in software although chatgpt was saying not likely but what if? I did read something about a braking command maybe I could use that command as a replacement for a "go to this position and hold" type of command? So chatgpt was against this approach but at this very attractive price point, size, simplicity, it is worth exploring at the very least IMO. It could be yet another nice pivot if we can magically manage to make it work somehow. Could be a bit of a game changer perhaps. And at the very least it is bringing in yet another tool, yet another option, another approach for the toolbox. That is helpful. The more methods we find the more we can apply the best method for each motor on a case by case basis for our 300+ motor robot.

Artbyrobot 08/23/2026 (Sun) 23:32:00 No.45085

It occurred to me I might be able to find more cheap ESCs in this size profile on aliexpress and I did find some offers that were far cheaper than amazon. The ones I bought on Amazon were'n't too bad on price but these were alot cheaper but take longer to ship from china on aliexpress. Here was my haul of 11 more: Also pay special attention to the first ESC in that list. It is for $3.25 each SHIPPED and that is CHEAPER than the cost in parts to make my own motor controller from parts. Now THAT is a deal!

Artbyrobot 08/23/2026 (Sun) 23:33:06 No.45086

Ok so with these off the shelf ESCs in route to me, I decided to go digging into what their behavior might be and how I might modify their behavior to fit what the robot needs rather than what a drone needs. Firstly, these ESCs run a firmware called BLHeli_S which is open source and is downloaded/flashed onto their onboard microcontroller via the two signal wires coming off the ESC. Now in a typical drone/quadcopter setup a separate microcontroller called the "flight controller" usually sends commands to each of 4 ESCs to get them to flight a little harder or a little less to achieve the right balance of the quadcopter or w/e or accelerate or w/e. The commands are throttle percentage and brake from what I gather. The analogy for these commands is they work the same way you use the gas and brake pedal of a car. So the gas pedal commands are press gas pedal hard or soft etc and that results in changes to acceleration and speed of a car. So you don't command the acceleration and speed directly but instead command the pressing of the gas pedal harder or softer. The brake command I believe is more stock though - it doesn't have a brake hard or soft but only a brake command I think. That's not good so we'd want to implement a change to make the brake command able to brake harder or softer just like the throttle command lets you do. In my setup, my arduino is going to be sending these commands to the ESC microcontroller just like the flight controller usually would. So my arduino is like the flight controller even though we aren't doing flight here. Anyways, the next issue is once they do brake enough to come to stop, they shut off power and go into a standby mode. That is no good. For a robot we'd want to brake enough to stop the rotation but once stopped we'd want to actively hold the joint of the finger say in place, not just have the finger go limp the moment it arrives at its desired joint angle. So that too needs to be added to the braking behavior. Another issue is that once the motor has not crossed a zero crossing back emf event for a certain countdown, it determines that the motor is stalled, and once it determines it has stalled for enough time, it gives up and shuts off, then periodically runs a start sequence again hoping to get unstuck. This is NOT what we want for a robot. When a robot finger contacts a obstruction, we want it to keep pressing on it indefinitely as that obstruction could be gripping a cup of water and that was exactly intended that the motor keep pressing at same intensity as it grips the cup. It is NOT to independently say ok we are stalling on this cup of water lets let go. That is fine for a quadcopter whose blade is stuck against a tree branch but NOT fine for a robot finger holding an instrument. Making the decision to let go or press the same firmness or press harder or press softer and how long to press is up to the arduino "flight controller" or even the higher level PC running the robot, NOT the microcontroller on the drone. That decision is above his pay grade. He needs to just keep pressing in that case and await further instruction beyond that. So that behavior also has to change. There may have been one or two other mods I wanted but those were the big ones that came to mind. Edit: actually one more thing: since we now have the motor when stuck just endlessly press waiting till it hits a zero crossing event, we have to first make sure it is listening for incoming commands during this endless waiting period and we also have to be able to command it to press harder or softer or reverse. However, if it is stuck because of some bug or quirk where it was advancing as normal then an obstruction pushed it backwards a bit and now it is waiting endlessly to detect a move forward that will now not happen since it is just commutating the same commutation step PWM endlessly and not attempting any further rotating of the 6 commutation steps anymore, it could just stall forever. So to fix this, we want to create a nudge command that essentially forces into a restart sequence that attempts to actively rotate the motor a full 360 degrees. This would break it past whatever infinite loop it had entered by accident. So basically this is the arduino flight controller's way of saying ok you aren't moving and should be, try to restart - the same way it would behave if it had determined it was stalling in its stock code but in this case the determination to try to unstuck is being made by the higher level microcontroller rather than its own firmware.

Artbyrobot 08/23/2026 (Sun) 23:33:29 No.45087

That being said, BLHeli_S firmware for the drone is almost universally upgraded now adays to a open source upgrade called BlueJay. You simply hook up a arduino to the two signal wires of the ESC, then plug the arduino into a PC, then you use a software suite calls BLHeliSuite I believe to flash whatever new firmware you want onto the ESC's microcontroller and boom, you have your modified firmware on the ESC and its behavior is tweaked. So using that workflow we plan to replace BLHeli_S with BlueJay, HOWEVER, the mods I mentioned in my last paragraph must be made to the BlueJay firmware before we can flash the modded version of the firmware onto the ESC. That said, to mod the BlueJay source code, one must first download the full code repository of BlueJay from github onto their desktop PC and then use notepad or w/e to view and edit the code which is stored in .asm files. The code is about 20 files and the total lines of code in the firmware is about 3k lines I think. All written in assembly language. Yuck. Then once one has modified the code to tweak the behavior as I've laid out, then one must convert the .asm files into a single .hex file which then must be flashed/downloaded onto the ESC. The conversion of the .asm files into a single hex file requires one to download the "Keil® PK51 Developer's Kit" which you can only download if you register an account on silabs.com. That kit contains the necessary 3 executable files that do the 3 conversion steps that convert the .asm files into a single .hex file. Those 3 .exe files are an assembler, a linker, and a hex converter. On windows I will have to run each of these .exe's using the command prompt to run them on the .asm files to convert to the .hex file. Or to make it a bit easier one can create a .bat file that runs the command prompt commands sequentially one at a time for you and so you double click the .bat file and the .hex file is made - boom done. That said, I downloaded that developer's kit and downloaded the github repo for bluejay and have studied the code with chatgpt and began formulating enough understanding of the codebase to begin plans for how to modify the code in the ways I mentioned without breaking the code. This way that codebase can be repurposed into a humanoid robot appropriate variant of an ESC rather than a quadcopter variant. This process is ongoing. I also want to credit chatgpt that 80% of the steps to get this far into this process were largely directed and assisted by chatgpt and would have taken me ages to get this far otherwise. For example, I thought maybe I'd learn how to change the firmware via youtube videos and the first video I saw was discussing the company history behind the company that originally developed and maintained BlueHeli_S firmware. It then went into details of that company's legal problems and politics and world events surrounding decisions that company made. I had to stop and leave the damn video. Holy crap I do not care I just want the ESC to work on my robot WTH! So it was back to chatgpt where I can just get the necessary info I want and not hear a million unrelated things that make me FORGET the original question I had to begin with. I just want my questions answered quickly and concisely so I can figure out what I need to know right away to then get to my next question that the first question pertained to and thereby in a uninterrupted flow of Q&A I can figure out exactly what is going on, what I need to do, why that is the best route to go or if there's a better route, etc. Note: I did consider just coding the firmware from scratch but after learning as much as I have about the existing firmware, it is VERY involved and complicated and clearly alot of time and effort was put into it and it is useful in many ways so at this time I think its best to try to mod it. But if modding it proves to break it and I cannot mod it successfully without screwing it up, I may have to rewrite it from scratch. It can be very hard to modify someone elses large and complex codebase for ME. I have rarely done this successfully and usually give up quickly due to being overwhelmed and unsure where to even start and unwilling to deeply learn their codebase enough to begin the mod to begin with. Other people's giant code bases tend to feel like a impenetrable fortress and tangled mess and making any change is not only a matter of finding the needle in a haystack of where you need to make that change but also understanding every downstream impact your change will have on other unrelated parts of their code so as to not break something else the moment your change goes into effect. And this feels impossible to do without reading their whole codebase and understanding it fairly deeply. Which is a HUGE time investment that borders on the same challenge difficulty of just rewriting the whole codebase from scratch. Its HORRIBLE. But with chatgpt's help MAYBE I can pull this off in a reasonable time-frame without too much pain. We'll see. I am NOT a big fan of assembly language coding but here we are. So I'm in this now. I'm committed. We'll see how this goes. I will probably wait to get the ESC to make significant changes to the firmware. I think I should make the code change then test it on the motor/ESC in a live test to see if the behavior changed and if the code all still works. If it does work then I can make the next small change. I can rinse repeat this until all changes are made and working. That is the plan for now.

Chobitsu 08/24/2026 (Mon) 14:59:03 No.45091

>>45087 >That is the plan for now. Godspeed, Artbyrobot. These ESCs look quite suited to many of our needs. I hope you can figure this out, Anon. Cheers.

Artbyrobot 08/25/2026 (Tue) 05:10:55 No.45095

Ok so after further consideration I decided that the idea of adding significant modifications to a 6k lines of code 20 file assembly language behemoth firmware developed by a big company was just not prudent for me. I need to be able to go in there and add tweaks and improvements for years to come and maintain my code there. The firmware of the ESC is absolutely essential to get just right as it has a massive impact on the performance of the final humanoid robot. The speed and fluidity of movement, the amount of strength, the amount of acceleration, it is all impacted by this. This is just essential. And assembly language is not in my wheelhouse. I am very inexperienced with it. So I officially decided to simply scrap their entire firmware and start from scratch coding firmware for it in C language. I have begun that process and so far so good. I will say though that the Keil PK51 Developer's Kit is an evaluation version and is necessary to convert the C code into the .hex file the microcontroller needs. The evaluation version limits your code size to 2kb which is unacceptable. To get the full version and get that restriction unlocked you have to fill out a form on their website (silabs.com) and they send you a code by email and you can then use that to unlock the software fully. So I did that and am now good to go on that front. While beginning this long journey, I also have been figuring out how single wire bi-directional communication between my arduino "flight controller" and the 8051 Busy Bee microcontroller on the ESC will be able to talk back and forth. I decided to make a custom communication protocol from the ground up for this which I will also then use for all communications between all of my various microcontrollers in my robot's microcontroller network throughout its body. So working out the details of that has also been a recent challenge. But with chatgpt's help I'm making steady progress and have a nice overall plan already. Things are moving along nicely.

Chobitsu 08/25/2026 (Tue) 05:39:02 No.45096

>>45095 Very intredasting, Anon. I understand your desire to avoid assembly in favor of C. Very sensible IMO. But devising your own comms protocol from the ground up? This seems a bridge too far to me. Not only is it reinventing the wheel (for no real benefits, AFAICT) it's also going to make this solution brittle. Unless the need is explicitly accounted for, interacting with standardized systems using well-established protocols will likely be impossible. Why not accommodate I2C or CAN protocols instead?

Chobitsu 08/25/2026 (Tue) 05:44:44 No.45097

>>45095 >>45096 BTW, this is a great resource for CAN Bus: The_Car_Hacker's_Handbook_-_Craig_Smith https://trashchan.xyz/robowaifu/thread/26.html#1000 I highly recommend you at least go over Ch. 5 of the book in detail before committing to some custom protocol.

Artbyrobot 08/25/2026 (Tue) 05:48:16 No.45098

>>45096 I just felt that existing systems have their own quirks and learning curves and making my own from scratch would make it far easier to understand it and I can modify it to overcome the problems I run into whereas off the shelf ones may have limitations I'm stuck with and problems I don't have the ability to adjust easily since its more black box, verbose, hard to understand, and not easy to modify. Now if I have to interface with a third party firmware, I can still do so with a standard protocol. But if I'm interfacing between my own microcontroller to my own other microcontroller that both were coded by me, then using my own protocol is more natural. Plus chatgpt knows everything about every protocol so he'll make sure I put in the necessary stuff from each relevant similar protocol into my own to ensure it has those important features. I just don't like mixing other people's code into my own codebases generally. The time it takes to learn theri rules and how to use could have been better spent making my own protocol and my own rules and in some cases ironically the latter can even be faster and give you a deeper mastery. Note: I don't think a custom communication protocol is a big programming project. This should be just a side note mini project I can whip up quickly.

Chobitsu 08/25/2026 (Tue) 14:42:07 No.45099

>>45098 Understood. While I'm still a bit skeptical, I understand the desire involved personally. Regardless, good luck with your efforts on this...I look forward to seeing your progress with it.

Artbyrobot 08/25/2026 (Tue) 18:44:58 No.45102

>>45097 > just use CAN Bus I asked gemini about CAN for our specific communications setup between a arduino and a ESC's onboard MCU as follows: "for can bus, does that work if you have 2 mcus connected together on an arbitrary digital I/O line with a single wire and a single reference ground wire and that's the only wires connecting the two?" --- And it said "No, standard CAN bus does not work with a single arbitrary digital I/O wire and a reference ground.Why Standard CAN Fails on a Single WireDifferential Signaling: Standard CAN uses two dedicated lines (CAN_H and CAN_L). It measures the voltage difference between these two wires rather than comparing a single wire to ground.Specialized Hardware: You cannot connect an arbitrary GPIO (General Purpose Input/Output) pin directly to a CAN network. You must use physical CAN transceiver chips to translate microcontroller logic levels into differential bus voltages.Bus Termination: A proper CAN bus requires 120-ohm termination resistors at both extreme ends of the two-wire cable to prevent signal reflection.Exceptions and AlternativesSingle-Wire CAN: Automotive systems sometimes use Single-Wire CAN (SAE J2411). However, this still requires a specialized single-wire transceiver chip and specific voltage modulation, not a raw digital I/O pin." --- So this means that CAN cannot be used between a ESC's built in microcontroller and a arduino microcontroller because only two wires (signal and ground) are involved between an ESC and an arduino's stock wiring connections and that pair does not have a built in CAN hardware chip etc. That is not a viable communications option then for this use case.

Chobitsu 08/25/2026 (Tue) 19:35:20 No.45103

>>45102 These 'objections' to CAN are all sound engineering design choices. Something as densly-packed with RF-emitting microelectronics and the veritable nest of RF-emitting comms cabling as an IRL working robowaifu... plus all the spurious signal noises of the general environment will do well to follow such design protocols. They've been tested in the "furnace" of production automotive vehicles for decades now. The pittance of add'l electronics involved to squelch such issues is a smol price I deem. Not to mention these CAN Bus electronics are commoditized to a 'dime a dozen' price points by now. My US$0.02 .

Edited last time by Chobitsu on 08/25/2026 (Tue) 19:41:10.

Artbyrobot 08/25/2026 (Tue) 21:20:56 No.45104

>>45103 Yeah, I definitely agree with you that CAN is a very robust communications method and that differential signaling would be preferable from an EMI standpoint if I were designing the entire ESC system from scratch. I don't disagree with that part at all. The problem is the specific hardware I am using makes retrofitting CAN radically different from just adding a cheap transceiver. These are already-completed off-the-shelf ESCs that I bought for around $3 each, which is actually cheaper than I could buy the individual components and build the board myself. The ESC's MCU is only a 20-pin chip and literally every pin is already being used for something. There isn't an unused CAN-capable pin sitting there waiting for me. So to add CAN I'd essentially have to redesign the PCB, except instead of designing a new PCB normally I'd have to perform microscopic surgery on an already-manufactured board: cut traces, tap into/re-route existing MCU connections, add the transceiver and supporting components, etc. And then I'd have to do that to roughly 300 ESCs. That turns a $3 off-the-shelf ESC into a major hardware modification project. Even if the CAN transceiver itself costs next to nothing, the labor and failure risk are enormous. A mistake could brick an ESC, and I'd also have to worry about introducing intermittent faults into something that was originally a known-good manufactured board. If this were one custom PCB that I was designing from the beginning, absolutely, I'd just design CAN into it. But that isn't the hardware situation I'm dealing with. That's why I'm pursuing the existing MCU interface and rewriting the ESC firmware instead. The whole attraction of these ESCs is that the manufacturer has already done the expensive PCB/power-stage work and is selling the finished board for less than it would cost me to reproduce the hardware myself. As for EMI, I agree it's something I need to test for. I'm not assuming single-ended signaling is magically immune to interference. But I don't think it's worth redesigning/surgically modifying 300 ESCs preemptively because CAN could be more robust. If the actual robot demonstrates communication problems once I have lots of motors switching simultaneously, then I'll have a real problem to solve and can look at the least invasive way to address it. So I definitely appreciate the CAN suggestion and I understand why you'd prefer it electrically. I'm just dealing with a very unusual constraint here where the hardware is already built, extremely cheap, and has no spare MCU I/O to make the retrofit remotely straightforward.

Artbyrobot 08/25/2026 (Tue) 21:24:45 No.45105

Also, if EMI actually becomes a problem, there are plenty of much less invasive things to try first: shielded wire, twisted signal/ground pairs, better wiring/layout and grounding, keeping signal wires away from high-current motor wiring, filtering or buffering the signal, and software error checking/retries if needed. I can test all of this under progressively worse conditions with lots of ESCs and motors running simultaneously before deciding I need anything more drastic. I'd much rather try those options first than start cutting microscopic traces on 300 ESCs.

Chobitsu 08/26/2026 (Wed) 04:29:11 No.45106

>>45104 >>45105 Yeah, that all makes sense. Glad to know this very-likely signals interference issue is on your map for this design application. Looking forward to see how you solve this. These ESCs do seem ideal if you can. Cheers.

Artbyrobot 08/26/2026 (Wed) 07:44:05 No.45107

While on my journey to develop the firmware for the ESC so far I was trying to figure out how to implement all the features the original ESC has to offer in its hardware setup but then it occurred to me that I don't need most of that stuff. And a lot of the complexity that was in the original ESC firmware I also realize I don't have to recreate or reproduce in the C language with my own style and formatting but can just leave out entirely. I recalled that my plans for a long time prior to now were to have the BLDC motors operate in a blind manner. This is called open loop commutation. Back EMF normally closes the loop or a hall effect sensor closes the loop or a encoder closes the loop but I had long ago determined I don't need a closed loop. All I need is for my code to instruct the stator's rotating magnetic field to advance through each of its 6 commutation steps either clockwise or counterclockwise at a certain speed and a certain acceleration/deceleration and to do so with a certain duty cycle which will dictate how much power it is moving with. So it can move with a lower duty cycle for a gentle touch or a high one for a rough and rigid or load bearing hauling effect while under serious load etc. Now the back EMF is nice for drones because they are trying to maximize thrust and do so as efficiently as possible but I don't need all of that. If my rotating magnetic field is too fast or not high enough duty and it happens to blindly pass up the rotor because the rotor can't keep up, I call that slippage or desynchronization. And some would feel that is not acceptable and that back EMF or an encoder would prevent that. The logic there is that slippage will result in a single lost revolution perhaps more than one resolution will be lost and that will make the motor's actual rotor location begin to drift further and further from the expected location so that the resulting end stop location will be significantly different from what was expected of it and therefore the accuracy will be thrown off and people feel this is unacceptable. However, consider the 3d printer (well at least the older ones not sure on the new ones), when they hit something or w/e and have some hiccup, the stepper motors sometimes skip or have slippage as I've been describing and that throws off the whole rest of the 3d print. Those 3d printers have no feedback but just give a best guess speed and power level and assume the rotor will always keep up and stay in sync with the stator and usually this is correct. They generally work great. But when they fail a print is ruined but that didn't make them unacceptable or useless. They just had a known less than ideal quirk we'll say. But they were accepted like that. So why can't my robot's stepper like approach to BLDC motor commutation be given the same treatment? And guess what? Unlike a 3d printer, my robot's joints will have a potentiometer measuring final joint angle - so this means that if some slippage and drift did occur along the way, the arduino reading in that potentiometer angle will detect that the motor is not where it was anticipated to be and the main brains PC will be made aware of this and respond accordingly - whether that be upping the duty cycle to increase power to blow past whatever extra resistive forces had caused the delays or slowing down to deal with the extra load it is surely under or if the duty cycle is strong enough, speeding up again more than before to make up lost time and get back to the desired location quickly that it had forecasted it would be by that point in time in order to re-coordinate that joint's movement with the rest of the body's overall animation frames it had projected out into the future and get back on track that way with its plans for the animation. So then the occasional hiccup, slippage, and drift is NOT a deal breaker or something that wrecks everything after all. And over time, the AI of the main brains PC can learn through trial and error to anticipate the slippage events and preemptively up the duty cycle or lower the speed to prevent the slippage from occurring in the first place the next time it takes on a similar task or challenge that previously caused a slippage event to occur. In this way, over time, slippage events will become more and more rare. So the AI can adapt and improve on those issues. This puts the burden onto the main brains PC to deal with preventing slippage rather than on the ESC to figure that out or use BEMF or w/e to try to prevent that stuff. And the main brains PC is a big boy - he can handle that!

Artbyrobot 08/26/2026 (Wed) 07:44:32 No.45108

All of that to say, we want to keep our ESC firmware simple, dumb, and very limited. This way it can be made very bug free and made more quickly and not require frequent revisions and updates to perfect it over time. It can be a staple. And then the adaptive main brains PC AI can be doing the heavy lifting and take on the responsibility to play that ESC like a musical instrument with great skill. Keep the ESC dumb and make the main brains PC be smart in its use of it I say. Keep the complexity higher up the food chain and let the dumb worker bot ESCs and stuff stay dumb and just follow orders blindly I say. So that is my return to my previously envisioned approach to this and I feel quite confident it will work out well and chatgpt agrees with me on that. Moreover, our arduino will also be measuring current so if we see a current increase it can be a collision detection clue and we can report that back to the main brains PC and he can then decide to up duty cycle or slow down to address the extra load or resistive forces that have been encountered - or it could be that this just indicates touchdown - like if grasping for a cup, slippage and current spikes can indicate that we have contacted and are now actively grabbing that cup and the main brains PC can instruct the ESC to just hold steady at a single commutation angle and stop rotating because we are now actively gripping the cup or w/e. So in that case it would not matter really. In fact, I really can't think of any scenario where slippage would be disastrous in its affect for our designs. Also of note is I do plan to put strain gauges on the fingertips so that would also help to know when grip has occurred and how hard the gripping is. So we have multiple redundant clues going on. And one more thing: because we have a 16:1 downgearing minimum on our BLDC motors, there are going to be a ton of full revolutions of the motor before significant movement of the joint even occurs. Alot of turns are just tightening up slack in the pulley system. So concerns about motor wiggle at startup and things like that making the robot seem like it has the shakes are also not going to be an issue for that reason among others. Also the fact that so many turns are involved to make a full joint rotation means that missing one revolution or two here or there from slippage is probably not even going to be perceivable because so many consecutive rotations are involved that you just wouldn't notice the slight delay that much as the rotations effect on joint rotation is so granular and small per rotation. The result of slippage would be a lot more dramatic if you had no downgearing or very low downgearing because every turn of the motor would then be much more noticeable at the point of observing the final joint rotation animation.

Artbyrobot 09/16/2026 (Wed) 11:44:05 No.45247

Ok so I had a breakthrough on communications networking within my robot. Originally I planned to have the main brains PC in the chest of the robot connect by USB to a "chest arduino" which would connect by single wire communication to a right arm arduino, left arm arduino, right leg arduino, left leg arduino, head arduino. So the chest arduino is forking out to all of those with each of those on a separate digital IO line connection with the chest arduino. This means the chest arduino was acting as a relay station to forward all the commands out to each of the main branches. Then those main branch hubs may then fork out to their various additional arduinos or ESCs as necessary. However, I recently had a lot of concerns about electromagnetic noise or static interference with this single wire communication which is something that setups like CAN bus addresses. However, I did not want to introduce additional chips and hardware. A very easy solution then occurred to me: CUT OUT THE MIDDLE MAN! Instead of a single USB to the chest arduino, I could have 6 or so USB lines coming right off the main brains mini itx motherboard pc and those can go directly to the left arm arduino, right arm arduino, left leg arduino, right leg arduino, chest arduino, head arduino, etc. This would be made possible by a USB expander port enabling that forking out capability since I don't think that mini itx motherboards come with that many usb ports natively as they are a very small motherboard with bear bones connectors and stuff to cut down on size. By going with USB I get a VERY high bandwidth VERY fast and VERY reliable from a electromagnetic interference standpoint data transmission system that is off the shelf. The USB cords themselves already have ferrite rings on them and have shielded wire as well. So they have a ton of protection. And the USB protocol itself is already very fast and high bandwidth so all the commands I would need both upstream and downstream will be very instant and cause me no headaches at all this way. And that cuts out the longest distance transmissions noise issues and speed issues. Remember that when the main brains PC wants a motor to brake or accelerate forward or w/e we want VERY VERY low latency on those commands both downstream and any upstream responses that let the main brains pc know what is going on. So a sort of hacky DIY single wire communications method with a DIY communications protocol made by me is NOT ideal AT ALL for that with all the noise it will face. HOWEVER, the single wire DIY communications protocol IS fine when going from right arm arduino to right arm ESC #7 or w/e which is just a very short distance of say 5-6" max. As long as we keep the signal line as a twisted wire pair with the ground return line and we keep it away from all the power lines when doing the wire routing and stuff like that we should be ok at such a short distance from a electromagnetic interference standpoint. So that resolution brings me some needed clarity.

Artbyrobot 09/16/2026 (Wed) 11:44:38 No.45248

That said, for the single wire communications protocol that will be used to communicate from the right arm arduino to the right arm ESC #5 we have had some great success. With chatgpt's help I think I have managed to initiate the microcontroller in code, wake it up and get it configured so to speak, and get its internal clock setup and running and defined in software so its accessible for timing, and also setup an interrupt function that reads the signal wire and anytime it goes from a 1 to a 0 or a 0 to a 1 it calls that interrupt function and that function takes note of what has occurred. Namely, when it goes from 1 to 0 it marks the timestamp of that transition to 0 and when it goes back up to 1 it marks that timestamp as well. It then calculates the duration between those two timestamps to see how long 0 pulse was held down. If it was a normal shorter duration 0 count, it marks a 0 in its buffer memory array. If it was a double duration 0 pulse that was held down, then it marks a 1 in its buffer memory array. In this way its able to decipher a message that comes sort of like Morse code in the form of 1s and 0s where the 0s have different durations that signify a 1 or 0 respectively. And then the main while loop main part of the program has a regular job of reading from this buffer memory array that the interrupt function is regularly populating and it gets this sequence of 1s and 0s and grabs 8 of them at a time and uses that sequence of eight 1's and 0s to consider that to be a byte/char. A char can be an A-z, a-z, 0-9, and several keyboard symbols. They all have a default char/byte representation in 0's and 1's that represent them. So in this way it can convert the 0's and 1's into plain text English. From there it then will determine whether it is reading just noise or a valid message format. My list of valid messages and their format so far is [Forward Nudge 5 5 5], [FORWARD 5 5 5], [Reverse 5 5 5], [Brake 5 5]. In each of these, note that they are enclosed in a opening and closing bracket. This is how my code determines if it is dealing with a potentially valid message or just random noise. If it sees that opening bracket it reads the 0s and 1's till it finds the closing bracket and then feeds the contents into a new memory buffer array and evaluates it further from there. If it finds a known command like like Forward Nudge # # # or FORWARD # # # etc then it considers it valid as long as that # is from 0 to 9. The 5 5 5 here is just a example figure of the parameters that come with the command. it can be any number 0-9 for each of these 3 parameters. I just chose 5 for all three for the sake of an example. So FORWARD 5 5 5 will mean turn the motor in forward direction (clockwise) at acceleration level 5 (or 50% acceleration), until you hit a coasting speed of 50% speed then remain coasting indefinitely.

Artbyrobot 09/16/2026 (Wed) 11:44:58 No.45249

Also while doing all of this use 50% power (which correlates to 50% duty cycle). So this way it controls how forcefully it will advance the motor, how much acceleration and how much overall coasting speed once it hits its full intended speed. Forward nudge will have the understanding that it is to nudge forward by 5 commutation steps (6 commutation steps is a 360 turn of the motor), and it is to do that at 50% speed and 50% power/duty cycle. So the forward/backward nudge command is for very fine movements of high precision and it is to stop and hold by default after a nudge. Whereas with forward command it attempts to rotate forward indefinitely until it receives the brake command. The brake command just tells it brake at 50% deceleration and 50% power/duty cycle. So this determines how fast it brakes and how powerfully it attempts that breaking. Once it has finished breaking it holds in place. So these commands enable the main brains PC to have tremendous control over the motors behavior and the fluidity and force of the motions of each joint. I still need to now test the code I have so far that implements all of this and debug it and then we can do live testing as well soon. I have NOT yet implemented in the firmware the actual movement code only the communications code for receiving these custom messages and the code that searches for these messages and validates them and breaks them down into commands to later execute on. Also I can always add more of these commands as needed which is quite nice. I know for example that I will need to setup commands for the ESC to report back if it runs into some kind of issues perhaps. We'll see on that though. Most issues will probably be picked up by a arduino that is going to be monitoring a shunt resistor and reading by that means the current being pulled by the motor and thereby know if the joint has collided with something due to current spikes that would happen in that case. Which is a type of collision detection system. It would also get clues from strain gauges which measure pressure put onto finger tips. It can also get clues from the potentiometers that will be connected to each finger joint that will tell the arduino the joint angle of that finger joint in real time as it changes. So with all of those feedback means, the ESC may not have to report back much of anything. I consider it just a blind and dumb electromagnetic field rotator. However one way it might answer back is that after getting a message and if that message contains a command to respond back, then it would respond back that it received the command perhaps. This would be a sort of heartbeat check the Arduino responsible for that ESC could use to make sure it got a message. However this may be overkill and not needed I think. We'll see.

Chobitsu 09/16/2026 (Wed) 12:53:32 No.45251

Thanks for the detailed breakdowns, Artbyrobot! a) I'm quite pleased to see you adopting a standard for your "long-distance trunk" wiring. (USB) b) Morse(-ish) is clearly a very tried-and-true way of doing text communications (potentially a little slow, but probably trivially so in this set of cases). The communications reliability is right up there! c) Simple set of programmable logic states. Simple is good. d) Implicit provision for future expansion of command sets. <---> I like everything you've said so far with one exception: >"...arduino that is going to be monitoring a shunt resistor and reading by that means the current being pulled by the motor and thereby know if the joint has collided with something due to current spikes that would happen in that case." This seems like both a risky approach from a safety perspective and also from a hardware wear perspective -- at least as the primary form of collision prediction/avoidance/detection schema. As a final safety failsafe fallback it's OK-ish. Any other alternatives you can think of for this set of needs? Regardless, again, thanks for keeping us all up to date with your progress Anon! Cheers.

Edited last time by Chobitsu on 09/16/2026 (Wed) 13:01:42.

Artbyrobot 09/17/2026 (Thu) 03:34:38 No.45260

>>45251 >current spikes are not the best way for collision detection why not? in any case the primary way is the computer vision. It should map its environment and prediction collisons based on knowledge of what is around it that is gained visually. The collision detection mechanisms beyond that primary are for cases where it doesn't know its about to hit something because it was blind sided. Like humans, if we are looking away from something and we trip on it or w/e because we did not see it. Unlike us, I don't think it will "feel" things from its skin having countless pain receptors or w/e and I don't know how to make something like that. And that seems pretty complex. But I did mention strain gauges in fingertips those will detect collision of finger tips with targets and I can place some strategically throughout the body to do the same thing. But I can only have so many of those really. They are hard to deal with and tedious to make and install. But they are another way. Just can't put millions of them everywhere though. But they can be like "feeling" things it hits though. And can measure how hard it is pressing on the thing it hits too. So those are two ways besides the current spike method. Also desynchronization/skippage events of rotor and stator gets picked up by mismatch between expected joint angle and actual joint angle which can indicate a collision so that's another way. So there are several ways. I just am not sure I get why you are very anti-current sensing as a way.

Chobitsu 09/17/2026 (Thu) 10:24:43 No.45262

>>45260 Hmm. Perhaps I overstated my position, or you misunderstood me Anon? Regardless, my primary concern on your behalf for such an approach is hardware wear on the robot's systems, and your human safety should such a scheme fail. Simple as.

Report/Delete/Moderation Forms

Delete

Password Delete only files (Removes the file reference to the posts) Delete media (Removes the saved files from the server)

Report

Reason Global