Society of Robots - Robot Forum

Well the straight spring wire acting as a finger joint spring idea was a bust. Turned out when it bent to 90 degrees it would not return to straight again. I thought spring wire would but this stuff didn't. This is not what chatgpt said would happen so chatgpt failed me this time. Anyways, still glad for its help when its right which is most of the time I think.





That said, I fell back to my original spring solution which was to use a 3mm diameter tension spring as the return spring. I experimented with different lengths till I got one as short as possible that would stretch out the necessary .75" roughly to accomodate the finger joint's reverse direction counter tension needs. The shorter the spring the more it resists being pulled and also the thicker the spring the more it resists being pulled. I used default thickness from my premade tension spring order and it seemed fine and the length of the spring I cut and tested trial and error till I found a good length for my need. For my .75" draw length I went with one 1cm long spring which stretches itself out to .75" + 1cm in total without ruining itself. It seems like it pulls around 2lb of pulling force but I haven't measured it with a scale. I fed it through bowden tubing from the place I mounted it on the motor all the way to the joint being actuated - the backside of the index finger. It's job is to keep the archimedes pulley system and winch in place pulley taught at all times and to return the finger to full extension when the motor is not actively pulling it into a grasp position. I have not yet tested if it is strong enough to do this job but assume I'll need two of them to be strong enough. I'll test with just one for now and add another spring to double it's strength if needed later.

I deliberated alot on where to mount this spring and last minute decided to just mount it on the motor it is counter tensioning since I have enough space for it there and I can just follow the same bowden tube routing the motor is using generally. This seemed easiest for me given my massive space constraints and the need for a ton of these springs to handle all the finger joints. Seems like it should work well so far.

A couple discoveries were made today.

#1- I noticed it was about impossible to pull from the bottom of the Archimedes pulley system and get the motor to unwind. After discussing the issue and potential causes with chatgpt for a while we figured out that the culprit is the tensioned string I put onto the output shaft of the motor to allow for snug unwinding and winding of the opposing string pair that I installed for manual turning of the motor shaft during testing. This tensioned string wrapped around the motor shaft only requires about 1lb of force to pull the motor enough to turn the motor output shaft. However, after the downgearing, to fight past that 1lb resistance to turning the motor output shaft would require 12lb of force since you have to divide the force applied at the output end by the number of downgear ratio you are at! And so after all points of friction in the pulleys and teflon tubing and the motor output shaft's magnetic cogging even while freewheeling we might be more like at 13-14lb of force required. And that is a TON of force to apply by just hand gripping fishing line. So I figured my system was just way too resistive somewhere or collectively and completely non-viable until we solved this issue! The 1lb at the motor might not seem big but it's HUGE to overcome when pulling from the backside after all downgearing. Wow. So we solved that big scare. I was very concerned and exploring alternative plans thinking we might have failed with pulleys approach before this was finally solved today. I'm so relieved. So once we remove those strings which are impeding the motor shaft from turning, we should only need a reasonable say 3lb of force on the back end of the pulley system, exerted by springs, to get the motor to unreel for joint extension back to default stance.


#2 - While exploring the aforementioned issues with trying to unwind the pulley system from the downgeared end, I began to realize the tension spring on the far side that unreels the motor and unwinds the pulley system has to be significant. I was exploring my options when an idea hit me: what if I used straight wires lashed onto the finger like a splint on the finger joint. I could put several fine spring steel straight wires parallel to eachother say .3mm in diameter wires and have them distributed as needed around the finger parallel to the finger. Then when the motor is done actively reeling in the finger to get the finger to flex, these resistive wires will be placing significant force to straighten the finger back out because they want to return to their straight state ASAP. By doing the return spring in this manner I save a TON of space since I'm putting it snugly around the joint itself and then don't have to put tension wires (a ton of them) into the forearm somewhere or w/e. I'm using space hugging so tightly to the finger that its space that seems unuseful until this idea came to me! So I pretty much deleted the volume taken by all the otherwise necessary tension spring wires if this idea works! I bought a large assortment of 40cm length spring steel wire off amazon to experiment and try out my idea. This could be epic! As a side benefit, these can act as additional support for the joint itself preventing sprains and dislocations of the bones and keeping everything snug and compact in a way that really helps support and aid the artificial ligaments I already have in place.

I had a eureka moment recently that I wanted to share. So basically I was thinking that I may not need to read back emf from a BLDC motor in my custom motor controller. Instead, I can have it just mindlessly advance the motor at a fairly low power mode by default and a default speed of advancement of the rotating electromagnetic field. Without feedback, it may overshoot, rotating faster than the output shaft and thereby skipping some turns. That is the reason why people want to read the back emf to avoid that issue and instead only advance the electromagnetic field forward at just the right moment - the zero point crossing moment. But I was thinking about it and realized that is not really necessary. For this application, if skips start happening, it doesn't really matter. To the degree that skips are happening, the motor will stop advancing the load with its winch system and this will show up when readings are taken by the potentiometer measuring the final joint angle. If alot of skips were taking place, the advancement of the potentiometer would not match the angle it thought it would be at were no skips involved and this would tell the motor controller that it has been having skips and give it an idea of how many skips as well based on the divergence of projected joint angle by now and actual joint angle by now. So then it would turn down the speed a bit or turn up the amount of on time of its pwm and thereby put more force into the rotating magnetic field to give a bit more oomph to the motor. It would then track progress by way of the potentiometer again and see if that solved it. If it still is skipping a fair amount that could indicate the load is more than expected or there is a jam in the system or it just needs more power and it could turn up the power more and slow the speed down more on its rotating magnetic field overall speed and try again. Rinse and repeat until it finds the sweet spot or finds out it simply cannot lift the load because its too heavy or there's a jam in the pulleys or w/e. So in a way then this would give it collision detection as well as the ability to have an idea of how heavy loads are based on how much it had to slow down and add forces to get the joint to move. I then see no real need to implement ANY back emf reading NOR any need for hall effect sensors etc to monitor rotation progress. The potentiometer on the final joint the motor is actuating is enough clues to tweak the rotating magnetic field to our satisfaction. By eliminating the back emf circuitry we greatly simplify the schematic of the motor controller, suffer negligible performance hit, and eliminate a lot of processing for the microcontroller chip handling the logic of many bldc motors simultaneously which means it can handle more bldc motors by itself. It doesn't get bogged down so much by having to read in all the zero point crossings as part of its routine. This saves on processing demands and processing speed demands. Getting this all to work in real time and perfecting it will require a fair bit of trial and error but this is how I'm seeing it working out and my proposed solution for simplifying things. I think it should work great! I'm excited to have much more dumbed down circuitry like this and to get to working on this soon. Just have to finish making my pulleys and then this electronics development can get underway again. That's why I've been thinking ahead about it a fair bit since it seems I'm likely nearing the end of solving the pulleys situation soon.

I?d love to dive deeper into this since getting rid of encoders could really open up cost-effective options for robotics. Thanks for sharing your thoughts so far!

I've had an epiphany. So in the winch in place pulley system I was working on before, my concern was that when winching in the string things would be taught and reliable but when the motor reverses and releases string, that is when any snags in the system could cause the string to not be taken up rigidly and tension on the system is then lost and the motor is then unspooling string which isn't being taken up which will result in a spaghetti mess of string spraying everywhere out of control and getting all tangled up. The solution I had was a constant tension spring attached to the turn in place pulley output that would ensure that always keeps the string in tension as the motor unwinds. However, that was a extra cost and complexity and volume taken up by yet another thing and when you multiply that out by 300+ motors that's a LOT of springs added taking up a ton of extra space. That is why I moved to a belt based system instead of string and winch based for the first pulley. So the epiphany was this: it hit me that I can simply have the spring that does the extension of the final finger joint be what puts tension on the whole system and then if at any point in the system a snag were to happen, rather than tension being lost as the motor blindly unravels, not detecting the snag, I could have the motor NOT actively unwind anything at any point! So the motor, when unwinding is to occur, will simply turn OFF, rather than actively drive the unwinding electronically. It can pulse width turn off just acting as a brake to moderate speed of extension but at no point do any counter clockwise release or unwinding of the string. This way, the system only itself pulls string off the motor output shaft and if the system at any point snags, the extension stops and the string is all still under moderate tension but just no further advancement takes place and the motor does nothing further but blindly turning on and off but not actually spraying out thread everywhere at all. Eventually, the potentiometer measuring the joint angle of the finger joint would detect things are not moving and the system would KNOW it has a snag somewhere and at that point it would perhaps try to contract then attempt extension again hoping to dislodge the snag. If this did not work, the system would go into a troubleshooting routine like notifying the user (myself) to fix it or fixing it itself or w/e. But no damage would occur in this setup involving a unraveling mess or tangled mess. Simply the snag itself would be discovered and addressed but no catastrophic series of failures would result in theory under this new setup.

So with all of that said, and this solution in place, I am ready to return to the turn in place style winch style first pulley setup I had before and then the Archimedes pulley will do the rest. So the first pulley will be 2:1 downgearing and the Archimedes system will do 16:1 for a total of 32:1 downgearing. No constant tension spring needed anymore! Much simpler now. Everything I was concerned about is then solved now.

The belt based system fix ideas I was going for may have worked but as of right now I'm abandoning that course. I prefer the winch style and think belts would be higher maintenance and slippage would perhaps be an issue even with all the changes I had mentioned to improve on it. The fact is, belts only have so much surface area to grip onto so they don't scale down too well to tiny pulleys IMO. Large pulleys are better due to large surface area and more for the belt to grip. So my super miniature belt idea was a bit doomed from the start even if it could have worked (and it may well have worked) it just isn't ideal theoretically and I'd rather go with something I trust more intuitively for now.