/random/ - random

1

Ok so I created what I'm calling the Orchestrator.py, a python code a couple thousand lines long that interfaces with chatgpt, being able to go into my codebase for chatgpt and pull sections of code out and populate my clipboard with that code and ask me to paste it in for chatgpt which I then manually do. Chatgpt outputs commands like list all sections of code in this or that file and if I copy this command, the orchestrator who polls the clipboard goes out and goes into the code file and parses out the code section names and populates the clipboard with it and tells me to paste it in to chatgpt which I then do and then chatgpt is like okay, these 3 code sections we are dealing with for today's project, pull out code section #1 - lists its name and I copy this request into clipboard and orchestrator goes out and pulls that section of code from the codebase, populates it into the clipboard, and tells me to paste this into chatgpt which I manually do. So then chatgpt fully is able to get up to date on the codebase and where we left off. Also backing up a bit, this ALL starts off for a new session in chatgpt with me pasting in a huge context dump about my various projects and the orchestrator.py and the commands it can give the orchestrator.py etc and kind of seeding its context window with what is going on. Then it begins issuing the commands to list sections of code or w/e. Next I have to manually launch the orchestrator.bin file which launches the python code of orchestrator.py which upon opening asks me what code project we are working on this session and gives a window with a list of coding projects we have ongoing. I select from that list the coding project we are doing that session. The orchestrator then takes the coding project I selected and opens up a context txt for that coding project that lists the overall goals of that project, the list of to-dos for it, the most recently completed steps, and where we left off, any constraints, any special notes or rules, any dependencies, any special files or directories the related project files are located in, etc etc. It copies this coding project specific txt extra information into the clipboard and tells me to paste that into chatgpt which I then do manually. So this way chatgpt now has overarching major context dump for all coding projects and then today's coding project specifics for that session. It is now fully equipped to be my coding copilot. The orchestrator saved me just a ton of navigating codebases and files and copy pasting all the time. That is basically its job, to be a bridge for chatgpt and I into the hard drive and the projects. My next plan for making this even more seamless that I have been working on is to make my own diy browser. This browser will then be my interface for chatgpt and will enable my orchestrator.py to tap into what chatgpt is saying to me without me having to copy output text from chatgpt into my clipboard for the orchestrator to see the output of chatgpt. The browser will communicate this output text via some method that the orchestrator.py can read. Haven't decided yet how. I think socket based client server communications tunnel is the normal way two separate programs communicate like this. Although I could just output to a txt file maybe? I have used just changing the title of a window's text as a way to have two programs talk to eachother. Sometimes high speed talking can be too laggy or buggy when talking via .txt file generation and deleting. But there might be workarounds for that. And it depends on rate of communication needs too I think as far as when bugginess kicks in.

So anyways, as far as the diy browser goes, so far it creates a socket, uses OpenSSL, creates the handshake, connects to a web server, creates get requests, downloads that request, parses some of that request, etc. So I've come a long way with it. My first server I'm teaching it to connect to is gmail. So far it will connect to gmail.com and get a 301 redirect to https://mail.google.com/mail > it detects this and it then redirects to that url. That URL then issues a 302 redirect telling the browser to go to https://accounts.google.com/ServiceLogin?service=mail which is the login page for google accounts. That is where I paused for now. So it now needs to detect that 302 redirect request and close the socket and close the secure connection handshake stuff and start a fresh socket and fresh secure connection and connect securely to the account login page.

I chose gmail as a test bed starting point for the browser since one of the things I want the browser to do is act as a very advanced spam filter but more. I want it to actually go into my spam folder and follow custom rules to locate certain specific types of spam and delete it out of the spam filter folder for me. Then when I regularly look through my spam folder for anything that is not spam, I won't have as much regular and obvious complete junk mail in there to sift through to find non-spam. I know you can use a couple popular 3rd party software to interface with browsers with your desktop applications like Selenium and Puppeteer but I prefer not to get locked into any 3rd party ecosystem for this kind of thing and want to DIY this instead for MANY reasons I won't go into here. Suffice to say I've wanted a DIY browser for browser related personal AI assistant related tasks like the spam filter filter of filters thingy I was talking about before as well as many other cool projects related to browser automation and I've wanted to do it from the ground up for years for many reasons. One of which is I simply want a custom browser in GENERAL even for personal use. For various reasons I want this to supplement Chrome and Firefox and Opera and Vivaldi and Supermium etc that I use already for various things.

So anyways building your own browser is a huge job but I think its a great asset for my goals. It will play a key role in my AI for my robot being able to use the internet to do many many things like researching, learning, watching videos, training, etc. I plan to have it be a very minimal diy browser that does bare minimum html parsing and display as well as parsing and displaying Javascript to a smaller degree. It won't be a full JavaScript engine it will just do bear minimum to get the key dynamically loaded content downloaded. I do not even intend for it to display websites as they were intended to be displayed by the website developers. It will just display websites as pure text with most images removed in many cases and it will often run in headless mode which means no graphical interface at all just console outputs only in many cases. It will often be moreso just a bridge between my AI and websites than a proper actual browser that people use with their mouse and keyboard to interface with websites as a human user of websites. But it WILL enable that form of use of the internet and websites as well as a optional use of this browser. So it will be multipurpose. One thing I want for it to be able to do one day is lets say the robot is fixing one of its own pulley systems and notices the ball bearings for pulley system repair are running low on stock. It can go online and order more ball bearings and doesn't even need to ask me first. It would just use my credit card and buy it. And one day ideally it would make its own money online and use its own money to repair itself so it doesn't use my money. I'd let it have its own money for its own maintenance and business ideas although the latter would be limited and need some oversight but could be a cool realm of experimentation that could be fun. So yeah, that is just one of like thousands of potential future uses for it.

Well and since I said this much I'll say a LITTLE more my philosophy and approach behind this custom browser thing. Because I plan to run windows 7 on the robot and use it myself, refusing to upgrade to Windows 10 and GOD FORBID the notoriously and INFAMOUSLY Windows 12 NIGHTMARE that is causing mass exodus of faithful Windows users to Linux in recent times, that really affects my long term planning. By choosing to stay in Windows 7, now all browsers are going out of support and websites one by one are no longer displaying saying I must upgrade my browser. Soon extensions will stop working and all things will start to be unusable one day. So by making my own Windows 7 friendly browser now, I don't EVER have to worry about losing the ability to use Windows 7 as my daily driver. Supermium browser is a legacy windows friendly browser that IS maintained and still works on all websites but is that guaranteed to be maintained 15 or 30 years from now? Not in my opinion. Better to just roll my own now if I plan to stay on Windows 7 forever. My next operating system upgrade may never come or may be Linux or may be my own custom operating system which I already started building. But in the meantime a bare bones custom browser will potentially turn into a great thing for me.

Now alot of the diy web browser progress I mentioned here I did the work on like 4 years ago I think and there's video footage on my youtube of me making it on my youtube channel. I was just continuing where I left off on this project recently is all. Did not get a ton done yet recently but did progress a bit. And I'm HOPING that with chatgpt and the orchestrator.py's help that I can code much faster now on the DIY browser development. We'll see. I think I do code a bit faster with it so far but I am still hoping to improve there.

As far as the robot electronics, I did manage to find my hotplate with temperature control knob and a nice glass vessel I can put on the hotplate with water filling it up half way that I can heat up to 110F or w/e the ideal is for the etching solution I'm using. Then I will put the plastic earplug container I used for etching the little PCBs inside that hot water and do the etching at these higher temps. So I have everything ready for that next step. I did not start making the motorized etchant agitator yet though.

I got together my temperature sensor and my hot plate and my glass container and some water and figured out where on the hotplate temp dial I need to be to get the desired water temperature. I then used label paper sticker and marked it off and wrote 118f on it which is the average temperature of that spot on the dial. It has about 15 degrees variance I think up or down. Good enough.

Next, I mixed up a batch of water and PCB etchant (Ammonium Persulfate crystals and water mixture) using a postal scale to get the ratios right. I mixed it into the bottom third of a wet ones baby wipes container. It was 0.8oz total. Then I submerged the etchant mix into the warm glass basin of heated water to bring it up to temp. I noticed the etchant wet ones container wanted to tip over so I used scotch tape to tape it off in all 4 directions to the glass container and pull it under water a bit too in order to maximize temperature transfer from the hotter outside water into the etchant container contents to warm it efficiently. I skipped the automated agitator entirely opting to just stir the mix with a hot glue stick manually.

All in all, it did etch within the 5 to 8 minutes range and I think etched even faster when the temperature was closer to 130f - closer to 5 minutes then maybe even 4 minutes I didn't time it. It was lightning fast compared to room temperature etchant which took 2-3 hours to etch a single board. So indeed, the instructions that said room temperature is fine were wrong. All that leads to is undercutting.

Anyways, with the stirring and the warm temps my results were significantly improved and almost every board was usable. I produced 8 or 9 in total. Enough to do at least 2 motors and part of a 3rd at least. So plenty for now. I had still a tiny bit of undercutting on the fine traces, but rarely enough to break their continuity. I will make the traces slightly wider in Photoshop for future prints with the expectation that around 15% of the outer edges will be removed so we print wider to compensate and then the result will be the width we wanted in the first place after the undercutting has done its thing. This way the undercutting is worked with and non-detrimental. That's my planned workaround for it.

In the rare instance of pinholes randomly in the center of pads or traces or a tiny open circuit on a thin trace, I am confident that a coating of solder over all of those areas will correct that. These little holes and whatnot are microscopically small so very easy to solder bridge as needed. I think for the most part my boards are almost all fully usable as is. I'm sure my methods will improve as I continue to tweak and iterate techniques over time - but the fact that we can already produce working circuits at this extremely fine detail and miniaturization level is already very encouraging. Any improvements from here is just icing on the cake IMO.

My next step will be to solder on the half bridge IC chips using the method shown in this video - a method I think looks very impressive and sound and hopefully not too hard to replicate on my end: https://www.youtube.com/shorts/r-HaRjBvWgU

>>152604

But would this thing fit up my ass? Honestly.

>>152607

perfect size for that but not sure why you'd ask that

Amazing that you are tangibly getting somewhere with this. Hopefully your little Rockman can learn to fight the corporo AIs.

Bump to get rid of the literal shit thread.

peak shit fr

I have taken great interest in your endeavours

I just saw someone upload real cp not too long ago.....on 8kun.....who is posting it? Could it be the FBI?

>>155424

nah shit sherlock, 90% of all pedos are in the FBI, i may be an athiest, but yall need jesus

The hard part for this is just going to be the programming

You could buy a humanoid bot and start there instead

I like this project though keep it up

>>157053

Those MAD DIY skillz. 🫪

>>157053

Uh… go on….

>>157088

Those circuits remind me of the hand-cut copper stuff from proto-comps… noice

robots download porn.....only a robot would be idiotic enough to download porn.....robots are the most idiotic thing ever......

>>157461

well if you make your own AI you can put in a rule to not download porn. That's why custom rules based AI is amazing. You can make any rules you want.

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.

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.

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.

How long do you think it will take to finally finish and have a working robot

>>158338

Too long to know like decades

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.