- Joined
- Mar 1, 2015
- Messages
- 291
- Reaction score
- 176
I said I would make this thread. Let's start things off with a GIF of it in demo mode:
Hopefully I've got your attention now. A quick rundown of the features:
15 36bit memory cells, not counting the cache and corresponding reference cells. Enough storage for 15 gestures.
Individual joint articulation. Unlike the 1.0, the 2.0 allows conclusive control of all the joints.
A programming interface.
A simple processor.
Demo circuitry.
Blacklist system(safety feature).
Full wireless connectivity for the select buttons and for the IO.
A system to link gestures together into one composite gesture.
Now that I've got this off of my chest, I can finally return to a more interesting, conversational tone. That up there is my new iteration of the Programmable Robotic Hand. Quite a jump from the original, I practically had to reinvent a primitive computer to get all the features I wanted. Funny thing is, I never tried to make a computer before, so even I am surprised at how well this turned out. Picture below:
Let's start with how the memory cells work: They are 36bit T-Flip-Flop memory cells They are accompanied with an additional 4bit memory cell that can contain an identifier for another cell, allowing you to chain them together. The memory cells can be selected through a 4bit bus. Only the memory cells with the same signature as the selection bus can be written or read. The memory cell outputs are bussed through each other into the output processor.
The output processor can do 1 of 4 things to the data. It can remain dormant, It can output the data directly to the hand to enter a gesture, it can rearrange some of the bits and output to the hand to exit a gesture(allowing me to reduce the memory footprint), and it can shunt the data back through the imprinting bus.
The imprinting bus is used to change the data in the cache and the memory cells. When you delete something, the memory cell is triggered to output to the output processor. The output processor shunts the data to the imprinting bus, tripping the activated T-Flip-Flops, effectively deleting them. Same process occurs when you delete the cache.
The Cache is where temporary data is stored. Any data you enter into it will appear on the screen next to the control panel. This is here to allow the user to create a gesture and even test it out before you finalize it. When you are satisfied, selecting Imprint Selected Memory on the control panel will delete the selected memory cell, and then imprint a copy of the cache on the same cell through the imprinting bus.
The Blacklist system is pretty complex. It is a safety feature to prevent player(and demo mode) from directly running a reference memory cell. If have a composite gesture in the memory, you could accidently run one of the 'frames' and break the hand(such as bending the fingers into each other). It is a pain to redock the parts, so instead of breaking the hand, it simply does not allow the player, or the demo mode access directly. It basically skips through all the reference memory cells, with a circuit to catch and flag the signatures that appear in the output. This takes a long time, so you can't be using it constantly.
The Processor, surprisingly one of the smallest circuits in the entire mechanism, allows the hand to autonomously enter and exit gestures, even follow the references to run a composite gesture. Currently, it runs a little to slowly for my liking, so if anyone has a suggestion for that, I would enjoy hearing it.
The Demo circuit, one of the most complex control circuitry I have made, yet it is only really active during demo mode. Basically it is a linear counter that is filtered to only output one output, and convert that specific output into a binary signature that can be shunted to the selection bus. The reason it is a linear counter and not a binary counter is because I needed to be able to skip any inactive or blacklisted cells. The intricacies of this system have a minor bug. When demo mode is run, the final bit at the end is always directly run, regardless of whether the cell is blacklisted or not. My advice, never use the final cell as part of a composite gesture.
I plan on eventually making a 3.0 version, focusing on simplifying the memory cell system and improving the issues of the current system, however, I am not going to worry about that for a while. In the meantime, if you have a question, just ask. Feedback is always appreciated. If you have an idea, I would love to hear it.
Also, before I forget, here is the hand itself. It comes with a guide in the post for programming it complete with pictures:
http://starmadedock.net/content/programmable-robotic-hand.2727/
Hopefully I've got your attention now. A quick rundown of the features:
15 36bit memory cells, not counting the cache and corresponding reference cells. Enough storage for 15 gestures.
Individual joint articulation. Unlike the 1.0, the 2.0 allows conclusive control of all the joints.
A programming interface.
A simple processor.
Demo circuitry.
Blacklist system(safety feature).
Full wireless connectivity for the select buttons and for the IO.
A system to link gestures together into one composite gesture.
Now that I've got this off of my chest, I can finally return to a more interesting, conversational tone. That up there is my new iteration of the Programmable Robotic Hand. Quite a jump from the original, I practically had to reinvent a primitive computer to get all the features I wanted. Funny thing is, I never tried to make a computer before, so even I am surprised at how well this turned out. Picture below:
Let's start with how the memory cells work: They are 36bit T-Flip-Flop memory cells They are accompanied with an additional 4bit memory cell that can contain an identifier for another cell, allowing you to chain them together. The memory cells can be selected through a 4bit bus. Only the memory cells with the same signature as the selection bus can be written or read. The memory cell outputs are bussed through each other into the output processor.
The output processor can do 1 of 4 things to the data. It can remain dormant, It can output the data directly to the hand to enter a gesture, it can rearrange some of the bits and output to the hand to exit a gesture(allowing me to reduce the memory footprint), and it can shunt the data back through the imprinting bus.
The imprinting bus is used to change the data in the cache and the memory cells. When you delete something, the memory cell is triggered to output to the output processor. The output processor shunts the data to the imprinting bus, tripping the activated T-Flip-Flops, effectively deleting them. Same process occurs when you delete the cache.
The Cache is where temporary data is stored. Any data you enter into it will appear on the screen next to the control panel. This is here to allow the user to create a gesture and even test it out before you finalize it. When you are satisfied, selecting Imprint Selected Memory on the control panel will delete the selected memory cell, and then imprint a copy of the cache on the same cell through the imprinting bus.
The Blacklist system is pretty complex. It is a safety feature to prevent player(and demo mode) from directly running a reference memory cell. If have a composite gesture in the memory, you could accidently run one of the 'frames' and break the hand(such as bending the fingers into each other). It is a pain to redock the parts, so instead of breaking the hand, it simply does not allow the player, or the demo mode access directly. It basically skips through all the reference memory cells, with a circuit to catch and flag the signatures that appear in the output. This takes a long time, so you can't be using it constantly.
The Processor, surprisingly one of the smallest circuits in the entire mechanism, allows the hand to autonomously enter and exit gestures, even follow the references to run a composite gesture. Currently, it runs a little to slowly for my liking, so if anyone has a suggestion for that, I would enjoy hearing it.
The Demo circuit, one of the most complex control circuitry I have made, yet it is only really active during demo mode. Basically it is a linear counter that is filtered to only output one output, and convert that specific output into a binary signature that can be shunted to the selection bus. The reason it is a linear counter and not a binary counter is because I needed to be able to skip any inactive or blacklisted cells. The intricacies of this system have a minor bug. When demo mode is run, the final bit at the end is always directly run, regardless of whether the cell is blacklisted or not. My advice, never use the final cell as part of a composite gesture.
I plan on eventually making a 3.0 version, focusing on simplifying the memory cell system and improving the issues of the current system, however, I am not going to worry about that for a while. In the meantime, if you have a question, just ask. Feedback is always appreciated. If you have an idea, I would love to hear it.
Also, before I forget, here is the hand itself. It comes with a guide in the post for programming it complete with pictures:
http://starmadedock.net/content/programmable-robotic-hand.2727/
