Artbyrobot

17/09/2026

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.

Send a message to learn more

26/08/2026

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.

25/08/2026

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.

25/08/2026

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. So I bought a haul of 11 more (see photo).

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!

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.

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.

23/08/2026

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.