Project Logs

Collapse

• Communications Between MCUs Progress

  Larry • 09/17/2026 at 04:08 • 0 comments

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

  Read more »

• Custom ESC Firmware Methodology and Technique Plans

  Larry • 08/26/2026 at 07:59 • 0 comments

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

  Read more »

• Coding Custom ESC Firmware From Scratch in C language

  Larry • 08/25/2026 at 05:18 • 0 comments

  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.

• Potential Pivot to Using Small Powerful Off the Shelf ESC

  Larry • 08/23/2026 at 23:47 • 0 comments

  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.

• BTS7960 Integrated Half Bridge Circuit Design

  Larry • 08/22/2026 at 09:04 • 0 comments

  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.

• Pivoting to Bigger Integrated Half Bridge IC Chip After Troubles

  Larry • 08/21/2026 at 11:38 • 0 comments

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

  Read more »

• Adding Breakout Wires for PCB Testing

  Larry • 08/09/2026 at 21:44 • 0 comments

  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.

• Adding Landing Pad for Every Unused Pin Of IC

  Larry • 08/07/2026 at 06:35 • 0 comments

  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.

• Separating Individual Pin Attachments of Left Side Landing Pad

  Larry • 08/06/2026 at 23:07 • 0 comments

  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!

• Integrated Half Bridge PCB Schematic Revisions

  Larry • 08/06/2026 at 00:54 • 0 comments

  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.

View all 109 project logs