Controls suck.
This entire 8 hour work session was about wiring the hand and making it work, which sounds pretty simple except its not. It’s not. After reprinting the palm and fixing some tolerance issues, I now have space to fit wires through the hand, but the issue wasn’t even wiring stuff onto a breadboard, it was the code to make it work. Every finger has 3 distinct degrees of freedom, and I need to manually calibrate/tune each degree of freedome by testing its range of motion in software and then mapping controls onto it.

And that was the easy part. The super annoying thing, is getting closed loop control to work. Because Im using relatively low torque and high speed motors, when trying to designate the fingers onto a certain position, they keep overshooting, which of course is the fundemental problem PD control solves. But tuning PD controls, and solving every wiring issue along the way, is proving to be mad annoying. I keep switching encoder pins, motor polarity, etc. which adds confusion because I can’t tell if the issue is software or hardware.

Anyways, after all this I’ve only finished 2 fingers ;(. But Im hoping the next few are going to be much faster, so that’s all for now…

Bruh fix lapse please.

I just lost 6 hours of work because the lapse didn’t save to anything. I’ve already lost like 15 hours, so this is pretty annoying. Anyways, this work session was spent assembling the hand. I know I keep saying this but for real though, I actually managed to assemble the entire hand and wire up the encoders. I still have wiring the motors left to do, and of course software as well, but this is huge!

I did notice, however that the fingers had a good amount of shakiness to them, so I am reprinting the knuckle bevels with tighter tolerances such that it is more robust. Also assembling the hand, and then moving it into various orientations is insane to see. Before assembly my vision for what I thought the hand would look like came from a static onshape document, I didn’t realize just how flexible 15 degree of freedom could be.

Splay between the fingers is especially lifelike, and despite the hand being large, it still looks good. The wiring situation is purgatory on Earth, but that’s ok. I should’ve made the wire passages much larger, but the filament roll, I’ve been using for the hand is running low, so revising the palm is unlikely. Overall, I am stoked with how its going…

…So, that’s all for now folks.

I have more fingers now.

Last session we left off, with another redesign of the finger after multiple prototype iterations. Well, this session was more of that, but I’ve finally arrived at a finger that is decent enough to work with. I added bearing, made it more friendly to wiring, and tuned tolerances, enough to not have to use glue! Given this, I’ve printed out 4 fingers only to realize that the base of each finger needs a wire peek through hole, so I’ll be redesigning and printing those I guess ;(

Besides that, this session I worked on physically assembling the fingers, which is more tedious than it sounds. I had to solder some breadboard cables and shrik wrap stuff, to use my motors with the standard pins. I also needed to solder wires to the encoder. So, after this I should technically have access to enough pins to program the finger, which is what the alst 3 hours of this session were dedicated to.

Normally, when I write code it tends to be “assisted”, but in this case I was really curious to learn the code. So I also choose the path of greater resistance by choosing to code the ESP32 in C++ through ESP-IDF rather than Thonny or Arudino IDE, like usual. It’s okay, I’ve learned a lot, and I’m only halfway through the script.

Anyways, that’s all for now folks…

Ayo call me Teo…

…the way my hand got ice on its wrist. Ok, ok ok, new intro style, but today’s session was about the wrist and a couple other things. First off, I realized that to express every character in the sign language alphabet you only need two degrees of freedom, so i worked on a differential wrist design to save space. Basically the wrist is just two stepper motors, with cycloidal gear ratio, that drives a belt to actuate the different axes.

Buttt, this was only the first half of this work session session. Off camera I printed the finger to test, and I realized a couple of problems and good things. First, the finger works how i intend it to, mostly. The major limiting factor is friction. On my design friction is both needed and should be avoided, so finding a balance is tricky.

On one hand friction between gears, allows the finger to hold position when oriented a certain way, which is good because it means the motor doesn’t experience any holding torque. On the other hand, too much friction stalls the motor out, which could lead to it dying. Basically, im using cheap ahh motors that are NOT designed for anything torque related, so I’m copping out and finding ways to make it work.

I plan to add bearing and limit range of motion through stoppers next session, so that’s all for now folks…

The end is near….
Of the hand design I mean. This session was basically fixing everything, I had concerns about from the printed prototypes of the hand’s knuckles. I made added better tolerances, and designed a neat palm to fit around th finger modules. The finished hand is around 30cm fingertip to wrist, so definitely on the “larger side”. But, that’s all right, because the design seems pretty robust. Also, I noticed that the hand resembled Edward’s from Full Metal Alchemist, so I wanted to add a reference to that somewhere, however it came off kind of weird, and I’m not trying to catch any larp allegations. Towards the end of this session i tried printing the hand parts to put together, but somehow for the fisrt time ever, my fricking printer’s nozzle clogged, so now I wait another 2 days while a replacement arrives >:(.
Until that time, I’m going to refine this design further, so I never have to touch the design aspect again (until the wrist of course). As for the wrist, I am lowkey scared that, this hand may require too much torque to make a reliable wrist for, given its size, but I’ll probably just suck it up, and stepper motors should work. Anyways, that’s all for now folks…

Ballright.
Today, I made a discovery. I learned that thumbs have one more degree of freedom than other fingers, yet they also have one less phalange. You see, being at the end of a hand, they have the degree that allows them to move diagonally, which pinkies also have an equivalent motio for. Any way, I only bring this up, because today, I decided to work on the palm, and more specfically the location of the thumb.
I found inspiration in this youtube video, and looking into the anatomy of our hand, its genuinely incredible how capable a thumb is. Also, during this time i made a correction to make the finger modules symetrical which saves space, and importantly gives me somthing to reuse for the thumb. Next sesssion, I’ll print out some of the designs I’ve tested and also design a palm.
That’s all for now folks…

Im really pissed.
I thought finally, after arriving at this design I could be content, and that everything would work as soon as i finished the distal phalanx coupling mechanism. But, no, there are more problems. Despite taking several hour brainstorming off camera, and then designing for another couple hours, a 4 bar linkage to couple the finger joints cuts off the range of motion, which i dont want to compromise.
This is because I reused the bevel joint from the knuckle, which saves vertical space, but not horizontal. Basicallly because of the way the knuckle works this hand has a breadth of around 150mm, which equates to approximately fingers of that length. My current design is not suitable for this, and so I plan to redesign everything from the knuckle up, to be more narrow and allow for coupling without sacrificing range.
So until then, that’s all for now folks…

HUGE BREAK!!
After so long deliberating the design choices to go with, this session I sat down and actually made progress on the design. As of last time I had developed a bevel mechanism to actuate joints, and that would be read by an encoder. This session I polished all those things, and developed the roll mechanism for the finger, which consists of 3 gears(24 -> 24 -> 12 teeth). Moreover, it just so happens that the dimensions of a servo fit approximately within the dimensions of the bevel mechanism, so I was able to fit the servo stuff directly underneath.
This provides a great form factor, and avoids the problem most servo actuated hands have with width(its only 40mm thick!). Also, I developed an encosure for the finger that is to be screwed onto a palm, thus ever finger is independently assembled, and the final design can be modular. Also, something that bothered me very much is wiring, motors and encoders between joints. Thankfully, within this design motors that drive joints are underneath the joints, which means they are closer to the wrist, and because I considered wiring, I was able to add channels and passages to hopefully get everything fitted without wires sticking out. In fact, the whole hand’s wires, should ideally come out through the wrist, allowing for compact control.
Overall, I am super excited with how this project is turning out, so stay tuned to see this get crazier ;)

Another redesign session.
The indecision continues, as this session I spent working on 2 entire concepts from scratch. The first idea, was to acutate the proximal joint of the finger from a servo, however, while this worked, I didn’t like how bulky it was. I had the short face of the servo move side to side to allow for roll in the finger joint, but that meant the long side was store in the palm. At this time I also came across some mini dc motors, and while they lacked position readings I also had just enough encoders, to make it all work.
So the second half of this session, I designed the finger module using n20 motors, and even animated its motion on onshape. I plan to simulate it on isaacsim possibly later, but for now this allowed me to determine collisions, without any math ;).
Anyways, that’s all for now folks.

Fusion is hard on linux.
This session, i’ve spent being indecisive about a lot of things. For one, I have been deliberating how I’d proceed with the hand design, specifically whether I would design a palm around the finger modules I have available, or redesign a hand from scratch. In terms of designing a hand from scratch there are a lot design considerations, I didn’t quite account for.
From the start I really wanted the hand to be direct drive, because I figured it would give me better position readings, and also because I wanted to differentiate my design from the hundreds of open source tendon hands that exist. Plus there is a higher strength cap, which doesn’t matter for my application but still. Anyways, during all this, I randomly decided, I was sick of windows, and switched to Ubuntu, which has been awesome, except for the for the fact, that all my work has been on fusion, which is unsupported on linux. There is a workaround using WINE, which is what I’ve been using, but it’s been so laggy, I’ve been genuinely questioning switch to onshape. Anyways, I’ve arrived at a decent finger design, which I think I will implement from scratch on onshape, so that’s what’s happening next session.
That’s all for now folks (obligatory larp terminal).

Folks.
I hate designing hands. Not really, but its kind of frustrating. Last session, I talked about how I am trying to design my very own hand, that is fully direct drive and 20 DOF(degree of freedom), so that there is a much greater range of the sign language vocabulary available. However, very quickly I realized that direct drive motors, involve embedding motors within the finger linkages, which leads to the motor size dictating the finger size.
Unfortunately the motor, I am going with(N20), is about as compact and powerful as I could find for this application. Not to mention they’re cheap, and include encoders for positional readings. The motors themselves, account for a very big finger, but also the finger joints being bevel joints make it significantly larger as well.
Thus, this session, I tried compacting the bevel joint, by using shorter gears, and removing free space. Halfway into this design revision I realized that clearing the free space in the bevel joint, would shorten its range of motion from 90 degrees to somewhere around 65. The first objective of this hand is to be highly dexterous, so I had to abandon the idea of shrinking the joint. I also got rid of bearing, because of the added complexity and material costs, they brought.
Next session, I intend to work on the roll axis of the finger, and then hopefully develop a palm, that can combine 4 fingers. But that’s all for now folks…
PS: the screenshot is of fusion crashing, because it keeps doing that ;(

I blew a capacitor.
For the first time in my life. Since last update, I’ve been trying to set up the demo with perf board, and realized the I2C lines were inaccessible. So giving up on that, I decided to breadboard it out. This would have been fine, if not for the fact that i took apart the entire breadboard for travel, which when I tried to reassembled, I must have messed something up, because next thing I knew there was a short in my circuit and the pwm driver had blown.
From this point, I made a decision to build my own hand, from scratch, that is robust, easy to assemble, modular, and best of all… my very own. Thus, this session was spent researching, how to approach building a robot hand. From prior context, I decided to not build a tendon driven hand, given their abundance in the robotics community, yet lack of implementation in real scenarios, mostly due to wear issues. Looking at the best hands in the world, I noticed most if not all of them were direct drive, and I am particularly a huge fan of the wuji hand. So, I’ve begun the design of a finger, using mini dc actuators, embedded withing the finger, allowing for a thing hand, that is precise and strong.
Of course the major drawback, I am not adressing is that the use of embedded motors makes the hand enormous. Like 6inch pinky enormous. In fact, I searched it up, and turns out the hand might be larger than Wemby’s. But that’s all right with me, as long as it works.
Anyways, I’ve attached a photo of the wuji hand, which I took inspiration from. But thats all for now folks….

HUGE PROGRESS

This session was spent, designing and assembling the electronics enclosure for the hand, and getting the full working demo. to be compact.

When the hand turns I noticed that servo cables would turn with the hand, which made accessing certain wrist positions risky, due to the nature of the wrist design. Thus I needed some way of reduceing the number of wires connecting to the hand, such that it can be more mobile. To do this, I decided to mount the pwm driver and power source directly onto the back, which I designed a bracket for.

Because the hand is shaped so oddly, it took me several iterations to find a mount that would screw readily, and the pcbs, the way I inteded. And while, I would send these designs to print, I worked on the electronics. I put tested the complete human to model to hand pathway, and I realized the whining sound and stunt earlier was likely a result of my battery supply. Thus, I switched out the battery for a wall dc-dc power supply, and was able to sustain the hand without a crash. At it’s peak the servos only drew about 1.2A at 12V, so perhaps the issue wasn’t the battery’s current capability, but instead how quickly it could provide it.

While I printed these iterations, I noticed how the elctronics on the breadboard were functional but fragile, so I decided to take on the UNNECESSARY decision to turn my electronics into a perfboard. Worst mistake ever. Who knew a perfboard could be so troublesome. Almost every 5 minutes, I’d either bridged a connection, soldered ground to voltage, layed out components in the wrong order, or just burnt myself. Even worse, I was laying on the dirty floor, and my shaky hands and burning elbows have left me more sore, than I’ve ever felt.

After some 4 hours recorded, and 3 hours off camera, I got perfboard wired up. Because, I’m almost at 10 hours, however, I’ll share whether it worked in the next log.

Good news and bad news.

Bad news is that this session was supposed to be a recovery log for the 4 hour lapse lookout accidentally deleted, except somehow the recording failed again.

Good news is that instead of waiting on that fix, I’ve kept working, and we’ve made some huge progress. The wrist design you saw last session was pretty neat, except when I finally got access to the hand to screw it on, I realized my screw tolerances were not enough. And worse that caused the screw to drag across the bearing of the wrist leaving that screeching sound, when a chalkboard is scratched.

So I fixed the finicky piece and reprinted it. In the meanwhile, I put together the electronics for the hand, and added the code I’d developed last night. After renumbering the pins, and messing around with stepper speed, I’ve finally gotten to a decent teleoperation phase with the wrist. It’s quite slow, but it works.

The only thing that concerns me, is that when I ask the stepper to move to a position to quickly, I hear a peep, then the fingers don’t move. Most likely somewhere downstream, overcurrent is preventing the stepper from drawing too much torque. This makes sense given how shoddy the wiring is…

Anyways, I’m about to rerecord the alphabet with my new wrist, and hopefully get the full demo working with wrist by next session. I will then hopefully, record a successful recovery session for my precious 4 hours of work ;(

That’s all for now folks…

This session is technically one in the future, because the sesison before this, I plan to log after this post. It’s kind of tricky, but basically lookout’s recording failed because I closed the tab, so now I’m rerecording the old session, while I work on the new one.

Mostly, I spent this time working on 2 things. One I noticed that my wrist, would rotte the entire platform, when rotating the hand, due to the rotational inertia, so I designed a brace to fix it in place. The other thing I did, was develop code for the wrist, so that I could add wrist encoder data to my sign language library, which I actually plan to record in a little bit.

Obviously this implies that last session, I designed the wrist fully, and printed it out, but you’ll find about that, next devlog…

That’s all for now folks.

This log is something I don’t do usually, which is a recovery log. My very first devpost, I ran into the issue on lookout where my video timelapse would save on lookout, but not add to hackatime, since the original recording link got closed. I was very dissapointed with this, as I’d lost my very first work session, which too was four and half hours.

Looking through the slack, it seems other people have had the same issue, and some people indicated that they solved it by playing out the screen capture on slow motion, for lookout. I implemented this, throughout this session, except for an hour of this session, the video was paused, hence the extra time. I hope this isn’t a huge issue; it wasn’t intentional.

To summaraize what the session was actually about, basically, I recreating my original component diagram, within a new project. This was because, the original, I felt, had many flaws, like for example the lack of net classes that were organized. Also, I was reconsidering the layout work of the original pcb. Mostly the work was transitioning my pcb into a new project folder.

Anyways, that is all folks…

This work session I added test points. This was something I noticed on many designs, especially for prototype boards, and I decided to implement them as well. This was tricky however, as my board is already incredibly dense, and test pads can take up considerable space.

After adding the pads, and re-updating my pcb from schematic, I noticed that all the 3d models were gone again. And worse, the custom footprint I designed for my bluetooth chip was also gone. The footprint for the bluetooth chip was especially tedious to make, as I added a bunch of zone rules like no copper fills and components, and such based on the application circuit.

This was and is frustrating, but I think the reason, was because my edits were saved to the pcb rather than to the footprint library, which meant refreshing the pcb page, lead to the changes being lost. I plan to fix this, by getting more familiar with the footprint editor, so my work doesn’t get lost.

Speaking of which, the next journal will actually be a recovery journal, as early on this project, I lost a four hour session due to a lookout recording bug. So, I plan to play out the screen recoding of the 4 hours, which has to be fair game, given how this is the SECOND time, I’ve lost a 4 hour session.

Anyways, that’s all for now folks…

Alright folks…

I know I already shipped this project, but I kind got an unexpected lead. So the reason, I wanted to leave off this project is because additional improvements, such as thumb dexterity or wrist movements would add rabbit holes that deserved projects of their own. But, the person who lent me the hand, also found the missing thumb; it does lack a shell, however. With that, I figured, I’m pretty close anyway, why not add the wrist?

So this work session was spent, predominately, designing a wrist mechanism where a stepper motor could rotate the hand into various orientations. The one thing, that concerned me from the start, was that stepper motors lack positional awareness. At least the kind I’m using does anyway. This means I would need to design a location for an external encoder to fit, that would stay fixed relative to the palm.

This design has been very tedious. The hand is already so compact, that the encoder would not fit, so I am thinking, I can attempt the stepper motor based wrist without encoder values first, and if i detect too much drift, then worry about that addition later. I’ve finished designing the wrist, and am about to send it to print and test fit. Next session, I will find out how that goes.

See yall soon…

Folks, this will be the final devlog. For this project anyway…

This session wasn’t too much involving actual additions to the project. Following last session, I was brainstorming ideas to expand this project, perhaps to make this a more robust system. In this search I encountered IsaacSim, a simulation software that enables the simulation of robots, which could allow for expanded training to grow the model.

But, in all honesty, I wasn’t too interested. Sure, I could add a wrist or thumb, and add more gestures, perhaps train a custom computer vision model, but the point of this entire project was to develop a rapid proof of concept. Given that I’ve achieved that, I’d like to invent my energy into developing a robot hand of my own.

That is what I plan to do next, however, that will have to be documented as a separate project, as it doesn’t exactly correspond with the purpose of this one. The rest of this session, I spent documenting my work, so check out the repo if you’re interested!

Anyways, that’s all for now.