My Advanced Realistic Humanoid Robots Project

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.

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. 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.

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!

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.

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.

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.

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.

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/public/documents/10/57/infineon-bts7960-ds-en.pdf?folderId=db3a304412b407950112b408e8c90004&fileId=db3a304412b407950112b43945006d5d&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.

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.

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.

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!

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.