Thu 27 Dec 2018

Mini-Grant for Development of a Transradial Prosthetic Arm

Bhargav Parthasarathy Public Seen by 122

> I had to cut out this introduction and the references section and post them separately because my thread was exceeding the Loomio thread character count, so I thought it made sense to post these two sections beforehand. I will post the rest of the thread right after this one; this introduction would have been the first thing, and references would have come last.

Hi everyone, my name is Bhargav Parthasarathy and I am an engineering undergraduate student. Over the past 18 months or so, I have spent much of my time researching the priorities and patterns involved in transradial prosthetic arms in comparison to more dexterous and biomimetic robotic arms. These interests have led me to my current work of building a competitive transradial prosthetic arm that improves upon current designs.

After detailing my project here and if given approval from the community, then submitting a proposal, ultimately I hope to gain as much funding as possible to support the full cost of the project. As a college student, I am unable to set aside enough money right now to fully fund this project due to tuition and housing, which is why I was interested in the micro-grant process.

Seeing as my goal here is to eventually submit a proposal anyway, I figured it would make more sense to organize my project details in the micro-grant proposal format which I am sure you all are more familiar with reviewing. I tried to make this as detailed as I possibly could and would appreciate any feedback. Thank you.


Stanford study: https://web.stanford.edu/class/engr110/2011/LeBlanc-03a.pdf
Prosthetic arm cost breakdown: https://health.costhelper.com/prosthetic-arms.html


Bhargav Parthasarathy Thu 27 Dec 2018

Description of Proposed Project:

The Problem:

Establishing the problem first, according to a Stanford study published by prosthetics specialist Maurice Leblanc the current amputee world population is now well over 3 million, about 80% of which are living in developing countries, and about 59% of which are below elbow (transradial) amputees. The latter two figures here are particularly important to note because with the far majority of amputees living in developing countries and majority being transradial amputations, this helps to explain why there is such a large focus (especially now) on designing low-cost prostheses that are in turn more accessible, with many if not most designs being transradial prosthetic arms. Looking at the average cost of a transradial prosthetic arm according to CostHelper Health's prosthetic arm cost breakdown, the shift toward low-cost transradial prostheses is further understood with the average cost of a lower arm prosthetic arm being $20,329 - a price most families simply cannot afford, excluding additional costs due to physical/occupational therapy.

Of course keeping the main goal of restoring as much motion and freedom to the amputee in mind, I have aimed to achieve this by specifically focusing design around balancing dexterity and production cost. After researching and understanding models like Open Bionics' Hero Arm, Exii's Hackberry arm, and Ottobock's Bebionic 3 among others, the effective balance of these two considerations is what I feel to be a gap in today's design of transradial prostheses.
If we look at the three aforementioned models more closely, this is helpful in describing the current state of prosthetic design and helps to justify the need for a more effective design.

1) With the Hackberry prosthetic arm being to the lower end of the cost spectrum, this open source design is impressive in keeping production costs to as low as $200, however, lacks in terms of dexterity. This is seen with the absence of wrist rotation, two-segmented fingers dependent on elastic force, relatively few degrees of freedom, off-hand dependent operations such as with thumb and preset control/selection, and an unreliable infrared distance sensor for control.
2) With the Open Bionics Hero Arm, this is an example of a transradial prosthetic arm in the middle of the cost spectrum at about $6,980. This design is certainly more expensive, but also more dexterous than the Hackberry Arm and even features an adaptive fit. However, it is still limited dexterity wise due to relatively few degrees of freedom with two-segmented fingers and a rotate-only thumb, reliance on the off-hand for preset selection and wrist rotation, and the fingers' reliance on elastic force like the Hackberry arm.
3) With the Bebionic 3, this is an example of a transradial prosthetic arm on the higher end of the price spectrum costing at least $11,000 and ultimately as much as $30,000 according to other users. Being much more expensive than the other two models, this model boasts better control algorithms and more advanced myoelectric hardware, but is still limited dexterity-wise due to relatively few degrees of freedom with two segmented and non-adaptive/rigid fingers, limited presets and non-instantaneous selection, and reliance on the off-hand for rotation of the upper thumb.

With these models in particular being similar to many others at similar price points such as with the similarity between the Bebionic 3 and Touch Sensitive i-Limb Quantum, they are good representations of the market and thus the gap in current prosthetic designs becomes more evident. This gap is summarized by the lack of dexterous ability in lower and even to a lesser extent higher cost transradial prosthetic arms due to:
- Few degrees of freedom
- Non-adaptive grips that are limited in terms of the range of objects that can be handled (ex. more delicate objects)
- Limited presets and non-instantaneous preset selection (manually scrolling through presets to find the desired mode)
- Unnecessary reliance on the off-hand (takes away from prosthetic hand's autonomous function)

As a result of these flaws, what we see then is the inability of current designs to, again, effectively balance production cost with dexterous ability.

Proposed Solution

As stated above with my transradial prosthetic arm design centered around balancing production cost and dexterity, this model will be made to incorporate the following features:

1) 16 degrees of freedom total (3 from each finger and thumb, 1 from wrist)

With 16 DOF, from this the prosthetic hand is much more biomimetic in both appearance and function with normal 3-segmented fingers that interact well with objects by allowing the full surface area of all three phalanges to be used. This relatively high DOF count in general has greater potential for more complex interactions and functions - much like the human hand.

2) Myoelectric control (using EMG sensors for movement of fingers and hand)

This will be accomplished by using two Myoware EMG sensors to measure the voltage on the opposing sides of the forearm muscles to determine when the servos will open or close the fingers. Because there are two EMG sensors here mounted on opposing sides of the forearm, these sensors can be used to both control the opening/closing of the fingers and bidirectional rotation of the wrist. For example if a single contraction is used to contract the left/right side flexor muscles, this can translate into opening/closing the fingers. Conversely if the users contracts the left/right side flexor muscles twice in rapid succession, this pattern would be detected to translate into the clockwise/counterclockwise direction rotation of the wrist (using the wrist mounted servo). The one function that will require the use of the off-hand will be the rotation of the thumb's base (metacarpal joint). This is because fitting a servo to do this motion was very difficult and determined to not be worth the added weight and cost.

3) Adaptive grip (designed to maximize surface area while gripping objects using a passive mechanical interface)

With the goal here being to allow the fingers to handle as many objects as possible, this is enabled by using servo driven gear actuation as opposed to traditional tendon and rubber band driven actuation. Because most prosthetic hands depend on rubber bands or some sort of elastic force to restore the fingers to the resting position (ex. Hackberry arm and Hero Arm), this also limits the ability to for example handle more delicate or brittle objects that break easily under force. This is especially the case when that force is not distributed over as much surface area as possible. Back to the first point, because rubber bands are not programmable to change how much elastic force is exerted/needs to be overcome in order for the fingers to move, as soon as one finger phalanx encounters resistance rather than just stop and allow the next phalanx to continue wrapping around the object, that phalanx will continue to exert an increasing amount of force on the object because the rubber band is continuing to stretch. If you are handling an egg for example, this is difficult because there is a fair chance that the egg shell will break if accidentally picked up using the bottom finger phalanges, and thus, you are forced to hold the egg or other delicate objects using the prosthetic hand's finger tips. This is even worse when considering the rigid design of the expensive Bebionic 3 because of the reliance on rigid mechanical links that make it such that if the bottom phalanx of a finger is stopped when picking up a rock for example, then the top phalanges will stop as well. My design aims to solve these issues because by using passive gear driven actuation, a very, very small amount of force (force of friction between gears) is required to overcome the resistance that each phalanx offers, and thus, the fingers are able to completely wrap around the object at hand before the servos apply any real force on the object. Using the previous analogy, this design would allow the fingers to completely wrap around the egg while hardly applying any real force to the egg at all, giving a much better grip. Furthermore depending on the preset that is active, how much force is applied can be restricted for example in a "delicate mode" preset where the current sensors tell the servos to stop applying force when a programmed threshold is reached.

4) Force sensing (using current draw sensors to detect load on servos)

As briefly mentioned above, force sensing will be enabled by the use of 5 current draw sensors for the 5 servos because of how the amount of force exerted by each of the servos against resistance is proportional to the amount of current that is drawn by the servos. Accordingly, for each of the presets that are programmed for handling more delicate or stronger objects, different current draw threshold values can be used with these current sensors. This will allow the current sensors to stop the servos once the threshold values are met.

5) Adaptive fit (inspired by Hero Arm design brace wrapping design)

Similar to the way the Hero Arm works, this adaptive fit works by allowing two outer covers on the left and right side of the stump's brace to tighten and loosen around the brace using a cable connecting both, and is controlled by turning a knob on one of the covers. This is useful because as the amputee's stump and brace change size, the outer covers can simply move apart to accommodate and wrap around the brace, without having to be replaced as often. Even when a new set of outer covers is needed to accommodate a large enough change in brace size, the outer covers can simply be 3D printed and mounted again using 4 bolts because of the modular design of these components.

6) Vibration feedback (proportional to force applied by servos)

Here, vibration feedback will be implemented as a way of allowing the amputee to "feel" how much force the servos are applying. This will work by using PWM on the micro-controller (an Arduino Nano) digital pins to alter the speed of the vibration motor depending on the current draw readings from the current sensors. Also to conserve battery, these vibration motors will only be active when there is a finger-controlling EMG signal active.

7) Voice control (using voice recognition module for much more instantaneous preset selection)

Because of the problem of having to manually scroll though different presets evident with the Bebionic 3 for example, this is somewhat tedious for amputees, and as a result acts as a limiting factor to the amount of presets that can be created. Rather, the approach with this design relies on voice recognition methods where upon saying a command phrase, the micro-controller will quickly activate the corresponding preset. This allows for many more presets to be programmed for different tasks or situations, because so long as the amputee can remember the preset commands, any one preset can be quickly selected by saying the correct phrase. A voice control module will be used for this.

8 ) Completely 3D printed frame (PLA)

Self-explanatory but just to elaborate anyway, the frame of this transradial prosthetic arm will be completely 3D printed using PLA due to its cheap cost and ease to print with. Of course with most 3D printed designs that are made out of relatively cheap thermoplastics like PLA or ABS, this means that should a part break or need to be replaced, this can happen at a very low cost and even be done by the amputee.

9) Some extra details

In an effort to have individual finger control using 5 servos, I also tried to keep a balance by providing as much torque to the fingers as possible while keeping the size of the servos down so that the arm is not too large. From this I have selected and designed around fairly powerful servos that at the 6V being provided will provide about 20 kg-cm of torque per each of the four fingers, and at least 4 kg-cm of torque for the thumb. This should make the hand also relatively strong compared to current models which often rely on 1) one servo to selectively control the 4 fingers and thumb, or 2) much more expensive linear actuators to accomplish the same function. As stated before, the prosthetic arm is going to be controlled using an Arduino Nano and will be powered by a 7.4V 4000 mah rechargeable battery pack. To power the servos and motor, this voltage will be reduced to 6V using a step-down voltage regulator. For force sensing, the current draw sensors will use the analog-in pins on the Arduino Nano. A protoboard on the side of the servo housing will be used for the circuits involving the servos, voice module, vibration motor, etc. Concerning the manufacturing of the gears, I am currently working on increasing print resolution so that the gears (which are fairly small) can be accurately printed using PLA, but for now this has been done by laser-cutting acrylic. For the connection between the forearm mounted servos and the finger mounted gears, this will be done using flexible driveshafts. Also by having the bulk of the weight from circuit boards and especially servos located near the stump in the forearm region, this reduces the amount of torque being exerted on the stump which is important in keeping the arm as comfortable and lightweight for the user as possible.

Expected results/impact:

After finishing building, testing, and refining this transradial prosthetic arm, I hope to see it become applied to an actual amputee. This would allow testing I imagine over short and then gradually extended periods of time to observe how the arm holds up in daily conditions.

Relative to the other transradial prosthetic arms currently available to consumers, I think that this arm will prove to be a competitive option that provides much more value given its relatively large amount of functionality as a prosthetic arm on the lower end of the cost spectrum. I also think that by moving forward to somehow make this design open source, this would increase its impact because of the accessibility and rapid community-contributed design improvements that come with ideas on open-source platforms.

Estimate of work effort involved:

What is already done

So far, I have the design fully modeled in CAD software which will be necessary for 3D printing components and for determining how to assemble the arm. As far as 3D printing/laser-cutting is concerned, all gears have been laser-cut and about half of the 3D printable parts have been printed, with some having to be redone due to quality issues.

What needs to happen

  1. My next step will be to draw out the circuit diagrams involving all of the electronic components which will be very useful in speeding up assembly time. It is also of course good practice in general to have this kind of documentation for future steps.
  2. As mentioned above, the next step for this project will be to finish 3D printing the rest of the parts. This is step 2 and not 1 because students are currently on break and I am waiting for 3D printing access when classes begin again.
  3. The next step will be to order parts which hopefully will occur if I am able to secure funding. For the parts that need to be ordered, I have the full parts list ready calculating the total production cost of the arm to be $425.02 (including 3D printing material cost approximation because not everyone has access to free filament). As far as how much in parts needs to be actually ordered, this number is $398.68 because it subtracts what parts I already have (one myoware muscle sensor) and also subtracts the estimated cost of 3D printed materials (because 3D printing materials are free for students). On the cost spreadsheet linked further down, the total amount of funding requested is $448.68 (added $50 to $398.68) as parts will very likely have to be replaced, and wiring supplies will have to be purchased (very difficult to quantify ahead of time). When ordering parts excluding what I already have, I will be ordering everything on the list except for the battery pack and flexible driveshafts which will be ordered after testing with code to confirm what the capacity of the battery pack should be, and modeling using tubing to measure how long each length of flexible driveshaft should be, respectively.
  4. After ordering parts and everything arrives, the next step will be assembly. Even though the CAD model shows everything to fit together correctly, there is still a chance that during assembly I might find that some parts need to be adjusted or re-printed. During this step, all such modifications will be made.
  5. After this is finished, I will need to write the program to control the arm using the Arduino Nano and subsequently test and refine this code.
  6. Next, I will use this code combined with extended testing to confirm what battery pack capacity is needed to power the arm, and after that is selected, the battery will be ordered. Subsequently, after measuring tubing to get an idea of what shaft lengths are needed, the flexible driveshafts will be ordered.
  7. Finally, the last step (after receiving and integrating the battery and driveshafts) will be to waterproof the arm's electronics to make it more durable in daily conditions. Any cosmetic modifications and finishing touches will now be added.
  8. With the prototype arm now complete, the next step will be to get in touch with a matching amputee (hopefully with e-nable's assistance) and conduct tests to receive feedback for improvements.
  9. After this cycle of testing and feedback reaches a point of satisfaction on the amputee's end, the design should then be ready for release through an open source platform.

Estimated timeline for completion:

The numbers corresponding with each time period below refer to the numbered list above and their respective tasks. Also, because this entire schedule is dependent on if/when funding is approved, for the sake of the timeline I am just going to assume that funding is approved on January 22nd if I submit this proposal ASAP with the community's approval. This is also when I get back to college:

  • January 1st - January 22nd: (1)
  • January 22nd - end of February: (2) (3) (4)
  • beginning of March - end of March: (4)
  • beginning of April - end of April: (5)
  • beginning of May - end of May: (6)
  • beginning of June - end of June: (7)

For steps (8) and (9), I really cannot give an accurate estimate for the timeline because of how many factors this relies on pertaining to the process of finding a matching amputee, the amputee's condition/availability, etc. which all have a very direct impact on how long testing and refining will take. Also as a note, the reason why assembly is predicted to take about two months is because of some of the parts suppliers I am looking to order from being located overseas in countries like China. From past orders, these deliveries have taken anywhere from 2 weeks to as much as a month. Lastly, not to whine too much but this upcoming semester's classes are expected to be much more difficult than the first, so should I be awarded funding for this project, I hope the people overseeing my progress understand if I fall behind my predicted schedule because of school work.

Names of individuals responsible for deliverables:

Bhargav Parthasarathy (me)

Amount of funding being requested:

Please refer to the following spreadsheet for all details regarding costs and funding:
Please be sure to click on the highlighted cells to read the notes I have included for important explanations.

A brief overview of my background with e-NABLE:

I have been a member of my university e-NABLE chapter since the start of the 2018 fall semester, so my involvement began fairly recently.


Bhargav Parthasarathy Thu 27 Dec 2018

Also here are some pictures of my design in CAD if anyone is interested.


Yoav Medan Fri 28 Dec 2018

Thank you for the proposal. Based on our experience, you may want to look carefully into the following:
1. Total weight as well as cneter of gravity. Heavy hand with an unnatural location of CG seem to be unacceptable to users
2. Energy source and capacity. Besides contributing to weight, it may discharge too fast.
3. Phantom pain - Many amputtees suffer from phantom pain when using EMG driven prosthetics. We are therefore working on an EEG-driven control. Currently we are using an ankle worn motion controller
4. It is possible to reduce the #DOFs to 1 per finger and still get a biomemtic design. Happy to discuss off-line.
5. The Thumb is the most important and perhaps most complex finger. From the illustration it seems to have minimal articulation.

Happier and Healthier New Year wishes to the e-Nable community


Bhargav Parthasarathy Fri 28 Dec 2018

Mr. Medan thank you for your comments, and I will try to respond to your points.

Regarding total weight/center of gravity, I realized upon reading this that I forget to include that in the thread, but I just ran the mass calculations in CAD and found the total mass to be 1174.55 g. As a reference point after doing some quick searching, I found that the average weight of the forearm and arm according to https://apps.dtic.mil/dtic/tr/fulltext/u2/710622.pdf was about 800 g and 450 g respectively. With the combined weight of the residual arm, however, the total weight of the amputee's arm and forearm should be closer to that approximation of 1250 g. According to this link http://bme240.eng.uci.edu/students/10s/slam5/considerations.html this prosthesis is a little bit heavier than supposedly the optimal weight of 1010 g. I also attached a picture of the center of gravity below, placing the point in the lower forearm region closer to the brace than the hand.

For the battery I will be selecting, you are certainly correct in that weight/discharge rate could be an issue, however, I have yet to actually confirm what capacity the battery should be and will determine it after assembly and code is written so that I can test for extended periods to find the current draw over time. So far, the highest capacity of 3.7V battery I could find was 4000mah which in order to produce 7.4V would require two to be connected in series, keeping the capacities from adding up.

For phantom pain, thank you for bringing this to my attention. Currently this design is intended to be EMG driven but for my purposes and if I even get to an amputee testing phase, should I have complaints regarding EMG resulting phantom pain, changes will of course be made. Because the EMG sensor setup I have right now does not distinguish beyond solely the presence of a signal in order to drive functions, the challenges that I see with converting to an EEG sensor would be not be too difficult beyond what wiring needs to be changed.

Regarding shortening the DOF to 1 per finger, I do not think this would be too desirable or allow for a very adaptive grip that could wrap around objects because only one joint would be available for extension/flexion. With an actual hand having 4 DOF per finger at 3 for each joint and 1 for adduction/abduction, the current design accomplishes this except for the 1 for add/abduction. The added cost as a result of 3 DOF per finger here is also not too high as all parts are 3D printed with the exception of 3 bolts and 2 standoffs.

For the thumb's range of movement, I think the picture may illustrate this poorly but the range of motion here is standard with most other prosthetic hands. This is given by 1 DOF for the swiveling movement in which that triangular thumb base you see can rotate 45 and 90 degrees, and 2 more DOF for the extension/flexion of each of the 2 phalanges.


Chang Liu Fri 28 Dec 2018

Hello! Great job on this detailed proposal! I can't find the vote button, not sure if I'm being dense or if voting is open?
I have a few queries on your design: What is the weight of this prosthesis? Perhaps you can make the weight even closer to the socket, but also debulk the socket area as that might be a hindrance and non-cosmetic. A dichotomy, I know.
Is your forearm area designed to be attached to a very well-fitted and suspended socket in all ranges of motion? If not, your electrodes will lose contact and become frustrating to operate. I see from the design pic that this design won't fit someone with a long residual arm due to the electronics being housed in the distal forearm, but if you're okay with that, that's fine and a good place to start.
I have undergone an Ottobock training for the Bebionic hand, and it's actually very good for adaptive grip even with the smaller degree of freedom. It doesn't have the highest grip strength but the adaptive grip is sufficient to make it very functional. And it is already very breakable and high-maintainance, with the amount of parts it has, so perhaps you'd consider making your finger parts less complex for a similar functional outcome? The most impt parts for grasp patterns are mainly the index finger and thumb.
From what I see thus far, your prosthesis is great in that it seems like a much lower cost alternative to a high-end myoelectric hand, which is really great. A few of the advantages of the Bebionic hand actually comes from its thumb movement: by moving the thumb to and from opposition, it allows different grasp patterns to be generated using the same muscle contractions. (primary and secondary grasp patterns for each thumb position, and co-contraction and 4-channel controls). It's worth looking into it, if it can simplify your hardware and make it lighter! Or it might make it too complex, which is more often not the answer. The accuracy of the signals being picked up will need fine-tuning too, I'm not sure if the noise of the voice control will affect that. I'm not the most familiar with this, but I know that inaccuracy of each muscle contraction translated into the correct movement can be frustrating.
I think this is a great proposal, but it'll take some work to make it realistically functional for a user, especially to iron out some common clinical problems faced by users before you face the frustrations of these during user trial, so your timeline might be a bit tight, if you wish to amend that. I'd be happy to help identify some of them in greater detail if you'd like as you go along, as I'm sure the prosthetists here would, they have much more experience than me in this. :) Good luck!


Bhargav Parthasarathy Fri 28 Dec 2018

Mr. Liu thank you for your comments, I will try to respond to your points. Also, you are correct in that there is no vote button; I wanted to post my draft proposal as a thread before actually submitting a proposal for voting so I could get some input on what should be improved first.

Regarding weight, as I am replying to all comments here I just detailed some information about weight I previously excluded in a reply to Mr. Medan which should give you some information. For debulking the socket area, actually your comment got me thinking about the right side of the socket (from the perspective of picture New_53), because that whole bulky portion is just the ratcheting mechanism to tighten/loosen the cables that connect between the outer braces, but this could just as easily be excluded and let there just be one of those spring locks for clothing instead like this image https://images-na.ssl-images-amazon.com/images/I/71QY1THUpEL._SX522.jpg which I see working just as well. For the left side of the socket, however, those gray and green portions you see are the battery and voltage regulator. Right now with everything in the forearm being tightly packed, it is difficult to relocate this elsewhere. Also being one of the heavier components, I thought it would make more sense to mount this as close to the socket as possible as this also helps to shift the center of gravity closer to the socket.

Regarding the attaching of the forearm to the socket, I don't think I discussed this enough previously but this is how the components are supposed to connect. The forearm is directly connected to the outer covers which hold the socket using a series of bolts to hold these components together, and another set of bolts to allow the outer covers to swivel open so that the socket can be removed easily, which in turn requires the cables holding the outer covers together around the socket to be loosened. I attached a picture below to help illustrate this.

Regarding the grip technique, I agree with you that the bebionic hand's finger construction is suitable for most scenarios after having seen videos of amputees using these arms to interact with different objects. That said, although probably not a very big issue, the bebionic arm's finger construction is relatively rigid because of the solid link between the top of the bottom phalanx and upper phalanx which forces the upper phalanx to rotate with the bottom phalanx in either direction. Because of this in some instances where given let's say an object's irregular geometry like with a rock for example, if you tried to wrap the bebionic hand's fingers around the rock chances are that both phalanges do not contact the rock at the same time unless you tried to orient/pickup the rock that way. This would mean that you would really only be picking up the rock with each finger's distal or proximal phalanx but probably not really both which means you also aren't using the full potential of each phalanx's surface area to enhance grip. The bebionic finger construction has been well done, but with my goal of improving wherever I can this is one area I thought could at least be improved slightly. Also regarding complexity and what you mentioned about the bebionic fingers being breakable and high-maintenance, in this case I do not think the complexity here is directly related to the breakability/maintenance of this arm. This is because although seeming complex, each finger is really a train of gears/standoffs secured by bolts on either side that will eventually be secured using loctite to ensure they don't slip out. With this, I cannot see really anything in this subsystem having to be maintained frequently, and because of the 3D printed construction can easily be replaced should something break. The ways I imagine this subsystem breaking is if enough torque is exerted to snap the gear teeth off, or if the finger is bent backwards suddenly which would force one or more of the three phalanges to break. To help reduce the chance of this however, I do plan on having a limiting current draw value to stop the servos from breaking the gear teeth if the motors can even supply that amount of torque, and printing those beige lower finger mounts out of flexible filament to cushion the blow if the fingers are bent backwards.

Regarding your comment about how the index finger and thumb are the main contributors in most grip patterns, I was thinking about this and did realize that there was potential to save some space/weight by replacing the high torque servos powering the middle, ring, and pinky fingers with lower torque servos. This would save 125.4 g (not too much money as both are similarly priced), and allow more room for housing electronics, but would significantly decrease grip strength. I think I will make this change anyways though; thanks for the suggestion.

Regarding the thumb, actually this thumb I think can do what you are talking about, as it is able to be moved to and from opposition which as you said allows for different grip patterns. This is done by using the off hand to rotate the thumb to either 45 or 90 degrees. For the fine tuning of the EMG signals, this also should not be a problem as I am not relying on the EMG sensor identifying different types of muscle contractions to translate into different finger movements. Beyond just an EMG sensor on either side of the forearm to detect when one or the other muscle group is active, no further distinction is made. As you stated with the difficulty experienced by EMG sensors in making this distinction in the forearm, I tried to avoid this by using presets instead which the user would select via voice control for whatever general type of task they were doing. For example if handling a computer mouse, this would work as the amputee would use the preset phrase for a computer mouse which would assign a different current threshold value to the current draw sensors, and work such that a muscle contraction detected by one of the EMG sensors would be a down-click and the other sensor's signal would be the release, or something similar to this.

Also, after posting my thread and thinking about this timeline a bit, I think for when I actually submit my proposal I am going to re-state my end goal to probably just be getting this to a developed proof-of-concept because of how difficult it is going to be for me to actually conduct long-run amputee testing and then actually getting this approved for clinical application. Also with many members having such a strong understanding of socket design and fitting and this being a field I am not that knowledgeable in, I think that releasing these files on a website and allowing someone to kind of take over that part of design might be better, especially if that someone already has experience with for example fitting amputees using methods like 3D scanning. Because the socket/outer cover portion of this design can easily be removed anyways by 4 bolts, I don't think this would be too difficult to change.


ebubar Fri 28 Dec 2018

Great effort into this proposal! Kudos for the detail that you've provided. I think its wise to let other models out there inform your designs. I'd encourage looking into the Po Paraguay MyPo arm as well (https://www.thingiverse.com/thing:2409406).
I've also got some tips that may be helpful. I've had some experience with the myoware muscle sensors and would suggest that you'll want the sensor cable shield kit and cable (https://www.sparkfun.com/products/14109, https://www.sparkfun.com/products/12970) to increase comfort and robustness of the device. Without the cable shield, you are very limited in placement of the electrodes which is a problem. We also found them susceptible to breaking and giving unreliable signals without the cable shield. I may go further and encourage that you try to get this system working with a conductive fabric compression sleeve like this (http://www.advancertechnologies.com/2013/03/diy-conductive-fabric-electrodes.html) to further improve comfort. I also think the weight and power load that you'll have in this design are going to be the biggest considerations for getting the system working well, barring any considerations with fitting to a user. Any clever workarounds to lower the number of servos would be wise as this decreases both those issues. I would definitely suggest borrowing heavily from the work of groups like open bionics and hackberry, as they've had large teams working on these issues and (especially in the case of open bionics) managed to bring their products to markets. There are good reasons that they've made the choices that they have made. I think the timeline is a bit tight if you haven't already worked out the electronics for the myoware muscle sensing. They're not easy to get reliable readings from. I've had a student working on it for about 8 months (albeit sporadically) and they're telling me they're at about 80% reliability for recognizing a muscle signal to turn into a pose. I'm also curious if your design considerations and solutions are meeting the requirements of the intended users. Its really easy to get lost in thinking about what we might think is most useful and needed (i.e. getting a hand that is as human-like as possible) while neglecting what an end-user actually wants or needs. Are all those poses really necessary, given the added complexity in motors? I'm a fan of balancing function with simplicity as there is definitely a line to balance along. It might be worthwhile to seek out a potential user. Along those lines, I think you can conservatively add at least 1-2 years to your timeline once you start working with a person. At a University you'll need to leap over some liability hurdles (hopefully with assistance from a faculty supervisor). This is non-trivial to get accomplished. Best of luck with the proposal.


Bhargav Parthasarathy Sat 29 Dec 2018

Mr. Bubar, thank you for your comments, I will try to respond to your points.

Regarding the myoware muscle sensor shield, right now I have two emg sensors designed to mount on either side of the stump for each of the two major muscle groups which after a quick search I believe are called the flexor policis longus and flexor digitorum profundus. I was just replying to Mr. Liu about this saying: "I am not relying on the EMG sensor identifying different types of muscle contractions to translate into different finger movements. Beyond just an EMG sensor on either side of the forearm to detect when one or the other muscle group is active, no further distinction is made. As you stated with the difficulty experienced by EMG sensors in making this distinction in the forearm, I tried to avoid this by using presets instead which the user would select via voice control for whatever general type of task they were doing. For example if handling a computer mouse, this would work as the amputee would use the preset phrase for a computer mouse which would assign a different current threshold value to the current draw sensors, and work such that a muscle contraction detected by one of the EMG sensors would be a down-click and the other sensor's signal would be the release, or something similar to this." From this, I have tried testing the Myoware EMG sensor on my own forearm before using simple wrist flexion and extension in either direction and was able to receive a simple readings that were high upon flexing the muscles, and low during relaxation without very much error. Because really these are the only signals I am looking to detect without trying to translate specific muscle movements into certain motions, I feel that the EMG sensor alone should be enough for this, but also because with everything so tightly packed together, it is difficult even after reducing servo size to house the Myoware sensors elsewhere besides directly contacting the stump, especially with the added size of the shields. About these sensors breaking easily, however, I was not aware of this and will take this into consideration by trying to add a protective case on the other side of its mounting place.

For the possibility of using a conductive fabric compression sleeve, I think this could work with my current design if the electrodes woven into the fabric could snap connect to the Myoware EMG sensor electrode points in the socket. However as I said with Mr. Liu: "after posting my thread and thinking about this timeline a bit, I think for when I actually submit my proposal I am going to restate my end goal to probably just be getting this to a developed proof-of-concept because of how difficult it is going to be for me to actually conduct long-run amputee testing and then actually getting this approved for clinical application. Also with many members having such a strong understanding of socket design and fitting and this being a field I am not that knowledgeable in, I think that releasing these files on a website and allowing someone to kind of take over that part of design might be better, especially if that someone already has experience with for example fitting amputees using methods like 3D scanning. Because the socket/outer cover portion of this design can easily be removed anyways by 4 bolts, I don't think this would be too difficult to change." Should the type of sensor also be exchanged for some other kind, assuming that a similar operating voltage is maintained and a similar wiring setup is maintained, interchanging this should also not be too difficult.

Regarding the factors of weight and power load, this was also an important point Mr. Liu brought up to which I responded: "Regarding your comment about how the index finger and thumb are the main contributors in most grip patterns, I was thinking about this and did realize that there was potential to save some space/weight by replacing the high torque servos powering the middle, ring, and pinky fingers with lower torque servos. This would save 125.4 g (not too much money as both are similarly priced), and allow more room for housing electronics, but would significantly decrease grip strength. I think I will make this change anyways though;"

Regarding drawing inspiration from models like the Hackberry Arm or those from Open Bionics, contrary to what my original critique might seem to convey I do actually admire these arms and have drawn design inspiration from these models in developing my own. Specifically, this was the case with the idea of a tightening/loosening set of outer braces featured on the Hero Arm, as well as with the idea of using gears mounted in one phalanx to articulate the next phalanx upon encountering resistance in the Hackberry Arm. I do believe, however, that there is definitely room for improvement in some areas which were those features I chose to discuss in the draft proposal.

About the requirements for the intended users, you are definitely correct about there being a line to balance function with simplicity. Actually with this model being my fourth prototype, I also realized this as I originally came from a design that looking at it now was absolutely crazy with each phalanx being able to be independently articulated from a total of 16 DC motors. Here, however, I have tried to make this a lot better and along the lines of what a lot of the field is doing with independent finger control but not really much else in terms of motor complexity. With the number of poses I mentioned in my original draft proposal, I think I meant to say that although this design has servos dedicated to independent finger control like other models, adding voice control to more quickly select presets also happens to mean that there is more potential for more poses, but not necessarily so many poses that it becomes unnecessary. In this way, I meant to say that more potential for poses is more a result of easier/quicker preset selection rather than having those 5 servos.

But as I was saying before with the amount of difficulty I expect to experience with getting to a point of working with someone on this, I am not ready to give up on the idea of trying to bring this to test with an amputee. But for the purposes of submitting a proposal, I will probably state my end goal as proving this design as much as possible to be a developed proof-of-concept just because I think there is some value in this design, and because at least that much I know can be an attainable goal.


Patrick Fri 28 Dec 2018

What is your coster breakdown? I see resources, but no cost for your project or details? Thanks.


Bhargav Parthasarathy Fri 28 Dec 2018

Hi Patrick, you can find the link to the cost breakdown under the "Amount of funding being requested" section of my draft proposal.


Patrick Sat 29 Dec 2018

Ah I see the comments now. Thank you.


Bhargav Parthasarathy Wed 2 Jan 2019


Thank you all for your comments as they have helped me to review my design and make changes accordingly.

I completed a basic wiring diagram between all of the electronic components I will be using to make sure that I do not have too few pins anywhere or missing components which right now looks alright. As described in the reply to Mr. Liu, I made the change to debulk the area enclosing the socket by removing the ratchet-tightening mechanism to tighten the cables pulling the two outer braces together, because the same can be accomplished just using a spring lock like those seen on backpacks. Regarding the servos I am using, just to reiterate I am using two 13.8g servos for the wrist's rotation and thumb which have less torque than the four 55.6g servos for the four fingers. In the reply to Mr. Liu, I said that I might change from the the higher torque 55.6g servos for the middle, ring, and pinky fingers to the 13.8g servos, however, I am not so sure that I can do this anymore because of the 13.8g servos are not continuous rotation types. It is possible to tamper with them to make them continuously rotate, however this involves removing potentiometer functionality which will in turn take away speed control, which is needed. Even looking at other continuous rotation servos, this is much more limited in terms of the balance between torque and size as all servos I have seen that are on the smaller side have significantly less torque (2-4 kg/cm) for the same or a higher price. Because of this, I will likely keep the servo setup I have as I am unable to find better continuous rotation servos that offer a little bit less torque in exchange for smaller size, less weight, and a similar price. Lastly as stated before, I do plan to update the end goal of this project: "...with the amount of difficulty I expect to experience with getting to a point of working with someone on this, I am not ready to give up on the idea of trying to bring this to test with an amputee. But for the purposes of submitting a proposal, I will probably state my end goal as proving this design as much as possible to be a developed proof-of-concept just because I think there is some value in this design that others could improve on, and because at least that much I know can be an attainable goal."

At this point if no one else has any additional input, I will be getting ready to submit an actual proposal with the information and changes I have detailed.


Jon Schull Thu 3 Jan 2019

As well thought out as this is, this strikes me as extremely (over) ambitious. You are not asking for a lot of money and I'm sure you'll learn a, lot but I fear you will end up contributing little. It would be nice if you could break this into a bunch of sub-projects, in such a way that even if you only succeed with the first one, there will be something usable and testable for other people to work with. Can you structure your project that way? If so, I suggest you propose the first sub-project or two with enough detail convince us all that it's doable and worthwhile, and layout the later sub-projects with just enough detail to convince us that there is a road forward....


Bhargav Parthasarathy Thu 3 Jan 2019

Mr. Schull thank you for your comments,

After reading this, I understand that given a multifaceted project as this one it is understandable that by breaking down the project into different stages this would allow everyone to see how design is progressing and whether the project is on track to be successful. I was thinking about this for a while as to how I should divide the project where the lines I drew between one stage and the next made sense in a way that would make as much progress as possible.

I think the best way to do this would be to divide the entire project into two parts which are 1) mechanical assembly, and 2) the integration of electronic components. To define these two stages first, mechanical assembly will encompass the assembly of all 3D printed parts using the hardware detailed in the cost spreadsheet (bolts, nuts, bearings, standoffs, etc.). On the other hand, the integration of electronic components will encompass components such as servos, the micro-controller, battery, voltage regulator, current sensors, etc. and their integration into the rest of the assembly.

Talking a little bit about why I chose to divide it this way, for the mechanical assembly, I realize that just including my pictures of CAD with descriptions here would not explain design as well as if given an animation or video of an actual model. This is the purpose of this step. By assembling the 3D printed components and hardware to give an actual model that can show exactly how the arm will work, this will give you all a better idea about this design and be helpful in getting funding for the second stage.

For the integration of electronic components, I chose to make this one stage rather than divide into many parts because I did not think it would make sense to test and prove electronic components that don't really have much room for error, before having to reapply for funding to purchase the next set of components. I say this as unique to the components I am asking for because I am not using any components that are very complex or difficult to use. With parts like servos or the Myoware EMG sensor for example, these are relatively straightforward to use for my purposes. I don't think it would be wise to separately request funding for things like this to test and show results of the EMG sensor translating into servo movement before again having to apply for funding for the next set of electronic components. I also see having this be one stage beneficial in that it is the quickest way to find any flaws if I am able to have the entire system working together. This would give me valuable information, especially regarding how much current draw I can expect cohesively, which would then allow me to confirm whether the battery I have planned is/isn't sufficient.

I would really like to hear your or anyone else's input on this organization before I submit a proposal structured this way, so please let me know what you think. Thank you.


Jon Schull Thu 3 Jan 2019

Thanks for your responsiveness (and thanks to everyone for the constructive input).

I think Mechanics and Electronic are good sub-sub-projects. I'd suggest that you define subprojects around sub-components (e.g., Thumb or Finger or Wrist) as well (which could then be broken into Mechanics and Electronics).

For example, a working Thumb (Mechanical and Electronic) would be a good stand-alone contribution and therefore good first sub-project. If you delivered nothing else, you'd still have delivered something that people could use and build on. A whole system like a hand (mechanical or electronic) is a big project and if anything fails, everything fails. That's what you're trying to ensure against.

I suggest you look at +Eric Bubar's current sabbatical project. Much less ambitious, much more modular, probably wider application, and probably more likely to succeed. Simple is hard!


Yoav Medan Thu 3 Jan 2019

A Thumb-up for an e-thumb



Bhargav Parthasarathy Fri 4 Jan 2019

Thank you for the clarification Mr. Schull,

I think I misunderstood what you meant the first time then, but I understand what you mean now. I am however somewhat confused about how I should go about approaching this project using standalone sub-projects built around sub-components.

With the thumb I have designed for example, my confusion comes from how in the context of the rest of the hand, the thumb is not really meant to be a standalone sub-component as it relies on a servo that is not mounted inside the thumb piece itself, but inside the hand compartment (see attached picture below). The reason I say this is because as a result if the thumb alone was assembled, being not entirely modular it would be just as valuable as if the rest of the arm was assembled simultaneously which would be more efficient, because both yield the same resulting thumb. Not being entirely modular here, however, I don't think this is much of a barrier in the way of improving on a component like this because although the servo is housed inside the palm area, the 3D printed thumb assembly can still be completely detached with all phalanges still intact, via 2 bolts. But again, with this design being relatively simple (cable "tendon" passing through thumb base to pull on upper phalanx) and a proven concept used by so many other tendon driven designs, I don't think it would be efficient to assemble this component alone before reapplying for funding to move on to the rest of the design.

Similarly, the design of most if not all of my arm's sub-components are like this where they aren't necessarily able to be stand-alone components, but can be easily modified and improved on because the only part generally separated from the component is the actuator, which also can be changed should whoever is improving on this design desires. This is because the method power transmission (flex drive shaft and cable) is independent of the type of actuator used.

Addressing the other two sub-component examples then which are the fingers and wrist, these components also follow this pattern as each of the four fingers can similarly be detached used two bolts to separate the 3D printed finger assemblies, but cannot function standing alone because the servo actuator is mounted in the forearm. Again here, I believe it would be more efficient to assemble the rest of the arm simultaneously as there would be quicker progress and the finger components would be just as valuable as if isolated. The wrist also follows this pattern but for a different reason as it was not so much designed to be a component in itself, but more an adaptation to the forearm's geometry to allow for wrist rotational movement. Specifically, the wrist component here really is only a servo attached directly to two 3D printed parts that sit on two bearings. Here, rather than a wrist which usually sits right under the hand that allows for the hand's rotation, the entire hand + forearm section rotates as one unit with the outer braces/socket remaining stationary to allow this rotational motion. This is to accommodate the flexible drive shaft passing through the "wrist" region which does not have torsional capabilities.

That said, I think that the best way to organize this project would still be by dividing the mechanical assembly stage, and the electronic integration stage. In addition to the reasons in the previous reply, such as giving a better illustration of how exactly the design works, the low-complexity of the electronic components I am dealing with, and the data that can be obtained from a cohesive electronic/mechanical system, I think this is the best way to improve rate of progress while giving enough focus to the development of each component. In this way, even if any component fails (as in the result of a design flaw), this could be fixed in the mechanical stage with the parts being redesigned and reprinted without allowing the whole system to fail. Even with the electronic components, failures here with a servo breaking for example would most likely be a problem with the servo itself as the power transmission methods used here are very simple.

I think the important question then when considering this should be specifically how a failure might occur, rather than if, and how this has an impact on the rest of the system because given a somewhat modular design, one failure may not necessarily lead to total failure.


Jeff Powell Thu 3 Jan 2019

Bhargav I am glad to see that this is well thought out and you seem like an able student.

Thinking in terms of funding: I would vote yes but here are my comments:
1) I agree with Jon that setting mini-goals within this project will be helpful.
2) I think it is important for you to share your progress, files, and what you've learned throughout the process so other can continue it rather than starting from scratch (this is a big, complicated challenge to our open-source movement).
3) make sure you've taken the time to see what options are out there on thingiverse and other sites, read the comments and (if possible) spoken to users. Size, aesthetics and weight are all factors that can doom a device.

4) for the bigger picture, it could be helpful for voters to know what the overall budget of the fund is. That would help address the concern that will almost definitely be brought up: "I don't think this should be funded because it sets a precedent for every other EM design to be funded" - which is a valid concern for sustainability of the fund. However, that doesn't mean the community should avoid funding anything like this, IMO. There's a balance between the all-or-nothing mindset.

I'm only able to mostly skim over what was written so I apologize if I missed something important.


Bhargav Parthasarathy Thu 3 Jan 2019

Thank you for your comments Mr. Powell,

I agree with the use of mini-goals in this project as they will definitely be helpful for me and whoever is following the project. About the open source idea, I also agree with this as you might have read in my draft proposal. I actually think I will start documenting all of my steps as soon as I start assembly rather than later, so that any difficulties or important details will be recorded, again for the reasons you outlined. Also, when you say budget for the fund, do you mean like a cost breakdown of the funding I am requesting or is that wrong? I assume this is what you mean because doing so would allow maybe not the total amount being requested to be immediately fulfilled, but could be funded in part based on how the funds are distributed (according to a cost breakdown), which should avoid the all-or-nothing mindset I think. If this is what you meant, you might have missed it but I included a cost breakdown spreadsheet with explanations in my draft proposal under "Amount of funding being requested":

"Please refer to the following spreadsheet for all details regarding costs and funding:
Please be sure to click on the highlighted cells to read the notes I have included for important explanations."

**Also quick update, I forgot to include the price of the DC motor driver in the spreadsheet at the time of the original post but that is now included which increased costs by $3.49. The actual DC motor is not included here because I still haven't quite narrowed down the exact link I am buying from, but the cost is very small anyways (looking to be about a dollar or maybe less), or I might be able to salvage one.


Bhargav Parthasarathy Mon 7 Jan 2019

Hey guys, I also had some questions about how the research approval process worked. Looking at an older thread about this process, I found this document: https://docs.google.com/presentation/d/1SClcxQl4IE6ycb2FXvYz6oalHsayDLRR_l1W90Jq-8c/edit#slide=id.p

Because this proposal will be requesting funding, according to the google slides document it will be reviewed by two reviewers from the e-NABLE research subcommittee. If this proposal does not get passed, would the reviewers give me feedback on the reasons why they denied the proposal and would I then be allowed to make any changes to resubmit the proposal? Also assuming the proposal does get passed, where does the money for the funding come from and how exactly does the researcher receive this? Thank you.


Bhargav Parthasarathy started a proposal Sat 12 Jan 2019

Mini-Grant for Development of a Transradial Prosthetic Arm Closed Sat 26 Jan 2019

by Bhargav Parthasarathy Sun 27 Jan 2019

Thank you so much everyone for taking the time to view, comment, and vote on my proposal. Having ended today having a total of 23 votes and 91% approval, based on what Mr. Schull has said I think my project should now fit the criteria for funding. I will be recording my progress either on a website or maybe for now on a google doc (haven't decided yet) especially once I can get going with 3D printing after our makerspace resumes normal hours where you all will be able to track and comment on my progress. Once I get that sorted out, I will post that link here. I appreciate all of the support!

Hi everyone, I attached my proposal in the form of a pdf instead of in this textbox as it exceeds the Loomio 20,000 character limit. The pdf is named "Enablio_Final_Proposal.md.pdf" and is in the same Markdown format. Hopefully this is not too much of an inconvenience.

Agree - 21
Abstain - 2
Disagree - 0
Block - 0
23 people have voted (17%)

Patrick Geary
Sat 12 Jan 2019


Patrick Geary
Sat 12 Jan 2019


Barry Maxwell
Sat 12 Jan 2019


Donna Zimmerman
Sat 12 Jan 2019

I think this is a fantastic project. Well thought out, well written, and I hope it has success. However, I think the schools should provide means for crowd funding or asking for grants locally. There are so many student projects and without any previous work with eNABLE, it would be hard to judge which students have the drive, skills, and campus support to be successful. I could support a follow up project after an initial project is completed with some information shared with the community.


Bob Rieger
Sat 12 Jan 2019

I believe the proposal is extremely well researched, comprehensive, and complete. I also believe the author graciously listened to, and accepted earlier comments and recommendations. The amount requested is modest, and I believe worthy of acceptance.


Jon Schull
Mon 14 Jan 2019

Bob stated my personal position on this proposal perfectly.

Appreciate all votes and helpful comments, in order to better capture community views. These proposals are helping us understand the kinds initiatives the community wishes to support.


Bhargav Parthasarathy
Mon 14 Jan 2019

Thank you everyone for the votes and comments. Really quickly, I did want to briefly address what Ms. Zimmerman said because I should have said something about this earlier. Regarding schools providing crowd funding and local grants, this is completely fair and actually my university does offer a crowd funding platform however it is a very lengthy process lasting at least 4 months, requiring the applicant(s) to continuously campaign, and charges a fee. Just to clarify


Bhargav Parthasarathy
Mon 14 Jan 2019

(Abstaining because I created the proposal)


Wayne Munslow
Mon 14 Jan 2019


Enable Sierra Leone
Wed 16 Jan 2019


Jeremy Simon
Wed 16 Jan 2019


Jacquin Buchanan
Fri 18 Jan 2019


Jason Bender
Mon 21 Jan 2019

I really appreciate the breadth and depth here but would like to see some things fleshed out as not to end up in the vast student project graveyard:

  1. Can you partner w/ someone with prosthetic experience?
  2. How will the weight of device will be suspended on the arm?
  3. How is backdrive of servos being prevented? Or servo "whine" (Hackberry fatal flaw)?
  4. How long is the wrist module (how short will limb need to be)?
  5. Can you self-fund smaller proof of concepts to validate sub systems?

Sandra Dermisek
Mon 21 Jan 2019


Donna Zimmerman
Mon 21 Jan 2019

I have changed my vote. My reasoning is based on what this project can give to the community as a whole. The thought-out answers provided to all concerns provide discussion that is of value to the community and shows that the requester is dedicated to helping those in need.


Richard VanderMey
Mon 21 Jan 2019


Jason Bender
Tue 22 Jan 2019

Changed my response. Clearly open to dialogue and suggestions for the community. I have my doubts about the feasibility of the project but if it is broken up into bite-sized pieces to minimize funding risk to the community I see no reason to stand in the way of an extremely marginal amount of money given the thoroughness of the proposal and answers to community questions.


Thu 24 Jan 2019

Agreed with Jason Bender. I welcome release of bite sized chunks of information, rather than the whole project at once. Please don't disappoint :)


Ken Bice
Thu 24 Jan 2019


Gilbert Cameron
Thu 24 Jan 2019


Thu 24 Jan 2019

I am VERY interested in your progress. I am travelling to Kenya in June where I plan to provide 3D printed arms to two children who fit the description of your profiled recipients.


Jeff Powell
Thu 24 Jan 2019

Bhargav has done a great job doing research for this proposal, addressing comments and responding to the community. I trust in him and this project.


Agi Gonda
Thu 24 Jan 2019


Thu 24 Jan 2019

I would highly encourage that this should not be built from scratch as well. There are a bevy of open source designs out there (e.g. open bionics, po paraguay) that have already solved many of the issues likely to be encountered. If we build off of others we make greater strides rather than continuously reinventing the wheel over and over. I can't count the number of engineering students who have proposed to revolutionize prosthetics and just end up essentially building an inmoov robot arm.:p


Thierry Oquidam
Thu 24 Jan 2019

Having to jump from Loomio to a PDF then to a google spreadsheet is not the ideal way of presenting a proposal for clear understanding.
If the outcome is around $500, no problem. If otherwise, I need to revise my vote.


Nate Munro
Sat 26 Jan 2019


Chang Liu
Sat 26 Jan 2019


Bhargav Parthasarathy Mon 14 Jan 2019

Thank you everyone for the votes and comments. Really quickly, I did want to briefly address what Ms. Zimmerman said because I should have said something about this earlier. Regarding schools providing crowd funding and local grants, this is completely fair and actually my university does offer a crowd funding platform however it is a very lengthy process lasting at least 4 months, requiring the applicant(s) to continuously campaign, and charges a fee. Just to clarify (cut/pasted this here instead of under the vote).


Bhargav Parthasarathy Mon 21 Jan 2019

Thank you Mr. Bender for your comments, I will try to respond to your points,

1) Regarding partnering up with someone who has prosthetic experience, I actually was able to do this last year in April/May where I worked with a prosthetist and discussed my design, what focuses amputees often look for from his experience, and how my design should balance those priorities. I got a lot of feedback from him about things like optimizing weight, center of gravity, simplifying certain functions, etc. which did have a large impact on my design as I went from my previous (frankly impractical) prototype to this one.

2) The weight of the device will be suspended on the arm using a set of outer braces mounted on a set of hinges such that there is some room for the outer braces to pivot to expand apart to allow some degree of growth or expansion. These outer braces are meant to tighten around the inner brace which will fit around the residual limb sleeve. This sort of loosening/tightening function was something that was inspired by the way the Open Bionics Hero Arm works if you wanted to get a better idea of this, but I also tried to keep the CG as close to the residual limb as possible to reduce the amount of torque the prosthetic arm is applying. Also as I stated in my proposal, my end goal here for the purposes of setting a more attainable goal is to make this as developed of a proof of concept as possible because of the amount of difficulty I expect to experience in getting to a stage where I could test this design on an amputee. Copied from the proposal, "This is not to say exactly that I am ready to give up on the idea of testing this design with an amputee, however, I think there is value in this design and by moving in an open source direction this would allow people who are more familiar and experienced in the clinical application of prosthetics to maybe take this design to that step. Also with many members having such a strong understanding of socket design and fitting and this being a field I am not that knowledgeable in, I think that an open source direction allowing someone to kind of take over that part of design might be better - especially if that someone already has experience with for example fitting amputees using methods like 3D scanning." I mention this here because of the way the device's weight will be supported in this design has a lot to do with how the arm is fitted to the amputee. Again, because this section of the arm is a separate module attached via 4 bolts, this can easily be revised should whoever looking to change this desires.

3) Regarding preventing servo backdrive/whine, I do not think this will be too much of an issue considering that I am using continuous rotation servos as opposed to standard servos. Going back to how these servos are being used in my design, the servos rotate as for example the fingers close around the object until a certain resistance is met which is in the form of a current draw value. When that current draw threshold is met, the servos stop turning or depending on what my tests show, the servos might be directed to continue turning at a very low speed to keep the amount of force being applied as constant as possible. Back to the main point about backdrive, because continuous rotation servos do not have a potentiometer telling the servo to keep applying force to hold at a certain position, backdriving the servos is possible. This is a good thing here because even if the servos are backdriven this will not result in servo whine (if the servo can stop rotating), or very little (if the servo has to rotate at a very low and constant speed). This video testing the servo I am planning to use might also offer some insight: https://www.youtube.com/watch?v=hSgzR5Ga-lU

4) For how long the wrist module is/how short the residual limb needs to be, with the whole arm being 17.87 in long, the the residual limb is about 4.59 in long. A longer/shorter residual limb will force the total length of the prosthetic arm to of course be longer/shorter, however this total length can be adjusted in the longer direction by adding space between the limb and wrist region but will shift the center of gravity by an amount depending on where that space is added.

5) For self-funding smaller proof of concepts, I think this relates to Mr. Schull's question about whether the project could be divided into sub-components/systems. For this, I answered with a long reasoning about why I thought it would be more efficient to divide the project into a 1) mechanical assembly stage, and 2) the integration of electronic components. Assuming you haven't already fully read that response, I would be glad to address any specific questions you might have about my method/reasoning there. Regarding self-funding, as I talked about the mechanical stage being what I thought to be a good way of validating my design and the concepts encompassed before moving forward from there, the amount of money in hardware required for the mechanical stage would be $82.73. At the moment this is not really an amount I can afford to self-fund without having to ask my parents; something I am really trying to avoid as I have already asked them for help with previous prototypes.

Hopefully these answered your questions and maybe changed your mind? Anyways, I would be happy to discuss any more concerns you have further.


Jason Bender Mon 21 Jan 2019

Hey thanks for your reply, my intentions is not to be discouraging, but just understand that Kickstarter/Youtube/Hackaday is a graveyard of student and/or maker projects that where going to do "ABC better than product XYZ for a fraction of the cost," but they don't get off the ground because 3d printing something that moves like a hand and making a wearable product are vastly different things. I appreciate your honesty about achieving the 2nd part though. As a prosthetist, I think your gear-based adaptive grip is the most novel out of anything you have proposed here, so I would focus on that mechanism primary if I could encourage you in any particular direction--but figure out that backdrive problem or it will be all for nothing! :)

A few thoughts:

1) I'm not sure you fully understand the problem of backdrive. If you don't use some kind of mechanical backdrive prevention (worm gear or leadscrew) then you have to continue to apply current to maintain grip force if the user just wants to say, carry something heavy across the room. This means ++ heat, ++ noise, - - battery life, and has been the fatal flaw in so many maker projects I've lost count. The cool thing about worm drive or leadscrew is you can completely shut the motor off once grip is achieved and you don't waste battery, don't make heat, and don't make noise.

2) The problem with the long wrist module is that it limits the amount of users that can use it. Notice almost every commercial design has all the electronics either inside the hand or external to the socket, that way no matter how long your residual limb is, you can still use the socket. Is it possible to do what you're doing but moving more parts inside the hand and/or external to the socket?

You've clearly given this a lot of thought so don't let me discourage you! Happy to change my vote (the money asked for is marginal) if you can consider some of the things I've said above.


Bhargav Parthasarathy Mon 21 Jan 2019

Got it; for the gear based adaptive grip I will try to demonstrate this first if I am given approval so that I can better show this concept to the community. Also about your distinction between how difficult 3D printing something and making that device wearable, I definitely agree with that. Again if I am given approval to start building, I will probably save my efforts to really optimize the "wearability" of this arm for last after getting the rest of the building process out of the way as my proposal goal implies. (Also, excuse my long reply)

1) Okay I understand what you mean now, previously I thought you were simply talking about the ability of the servo to rotate backwards given resistance. If I were to incorporate a backdrive option from the ones you listed, I think the worm drive would make the most sense as I am going from rotary to rotary instead of a lead screw going from rotary to linear. There are some drawbacks to this however that I am having trouble considering such as with speed. If I do go with a worm drive system, this will decrease the speed of the fingers considerably unless I adjust the angle of the worm wheel and worm gear threads drastically enough to warrant a 1:1 ratio, however the more this is adjusted the easier it is for the worm gear to backdrive against the worm wheel. With the high torque ratio the servos I am using are putting out already, I start to get the idea that users might become frustrated or see the slow speed of the fingers as tedious as opposed to a more instantaneous grasp. Currently, I was planning to rely on the gear train friction and current of the servo which work against rotational resistance especially given the high torque ratio of the servo putting out 20 kg-cm to hold the force applied with maybe some motor assistance depending on the task/preset (even though this trade-off will use some battery and produce some heat and noise). The other issue I was thinking about was compliance because if sudden forces are applied to the fingers in either direction, it would be a good thing if the fingers are able to accommodate this which a robust design should do. With an anti-backdrive system like a worm drive or lead screw system that will most likely have to be 3D printed to get the right ratio and be fitted onto the servo, if sudden forces are applied the worm wheel/lead screw would not permit any movement making parts like the worm wheel/lead screw threads susceptible to snapping assuming they are the weakest points. I think I have a work around to this instead though, by using a sort of locking mechanism like a ratchet, but in a manually locking way. By having 4 manual push-locks for each of the 4 fingers (not thumb because thumb is cable, not gear driven), this would allow the push locks to engage the lowest gear on the finger which drives the rest of the gear train, such that the lowest gear and the rest of the train get locked in place. For example when holding a heavy grocery bag, I think this would work well instead of a ratchet which is difficult to implement because of space and noise. As for actually implementing this into my design, this will be easy to accomplish because I don't need to alter anything inside the hand, but need to add mounts to the back cover for the push locks. This can then be retrofitted with the rest of the design. As far as when I am going to implement this however, I do think I am going to wait because I want to see how much force it actually takes to backdrive the 20 kg-cm servos because if this is sufficient to hold force for most applications with/without minimal servo motor assistance, this change might not be worth it. If it is relatively easy to backdrive, then the all parts for the change can be 3D printed and no extra hardware is needed so I will not have to request anything.

2) About the length of the wrist module, I agree that this is a limiting factor. Actually in my old prototype, I tried to keep the ability to accommodate as many different length residual limbs as possible by housing the DC motors used for actuation in the fingers themselves. After talking with the prosthetist I mentioned however, he reinforced the idea of keeping the arm as lightweight as possible as a major factor amputees consider because although the motors used were fairly small and lightweight, the combined weight but especially the placement further away from the socket placed a lot of torque on the residual limb. I tried to use this same idea here also because the servos are too large to fit in the hand area. By placing them right in front of the socket this was my way to minimizing the amount of torque exerted on the residual limb. I do understand that the trade-off because of this is a narrower range of residual limb lengths but I thought this tradeoff might be worth it also if the servos and rest of the electronic components are close in proximity. As far as making these parts external to the socket, I am currently doing this with battery pack with that rectangular extension on one side of the outer braces in the picture, however I don't think I can really do this with the servos because this would add volume around the socket area. I was trying to avoid this after I was advised by Mr. Liu to debulk the that area where I previously had a tightening mechanism but removed it in place of a more compact method. Also for custom fitting this to an amputee, this would be difficult because if the length of the outer braces/inner brace is lengthened/shortened depending on the length of the residual limb, this would mean that if the servos were mounted externally around the socket then the length between the servos and hand would change length, altering the length of the flexible shaft that needs to be ordered. From a sourcing perspective, I see this as being problematic because of how long it takes the Chinese manufacturers I am currently looking into to produce and ship custom flexible shafts (around a month), whereas if that length is fixed, this sacrifices a bit more torque on the residual limb in exchange for an easier custom fitting process and a less bulky socket/brace region.


Jason Bender Tue 22 Jan 2019

I think maybe you can see why some of the designs you mentioned in your proposal make some of the compromises they have. While the wish list is certainly fully-articulated, lightweight, low-cost, in reality those things all become difficult to fit together in a package that is cosmetically appealing and acceptable to a large variety of users due to the ALL the additional factors (like battery life, weight, where to put all the electronics, etc).

FWIW I'm willing to change my vote as you appear open to addressing issues raised by the community.

A few additional thoughts:

1) Your manual lock solution is a possibility, but do understand it does go against your design principle of minimizing bi-manual operations.

2) If you're not using a potentiometer to control the servos, have you looked at using standard DC motors or gearmotors instead? That way you could choose the output speeds you want and could potentially work in a worm-drive setup. Just a thought.

3) Don't underestimate the compromise of decreasing your battery life and adding heat through constant-powered grip to fight backdrive. Like I said, this issue killed the Hackberry, and EXTREMELY elegant and highly-funded design, not to mention countless other Youtube/Kickstarter/Hackaday designs.

  1. You're right that adding some of fail-safe for the fingers is a nice design feature. Lot of ways to do this besides allowing backdrive. Lot of commercial designs use a breakaway pin or knuckle joints that "pop out" under too much force. That way they can snap back in place and carry on. Again, not saying you need to do this, just adding some information from my experience.

You've got a HUGE task ahead of you, but I think if you can break it up into bite-sized chunks to minimize funding risk from the community I won't stand in your way!


Bhargav Parthasarathy Tue 22 Jan 2019

Firstly, thank you Mr. Bender and Ms. Zimmerman for changing your votes, I appreciate it a lot! To respond to your comments Mr. Bender:

1) You're correct, I think I am being a bit of a hypocrite here by including a function that would require the off-hand when I described my goal to partially focus on minimizing use of the off-hand. In total then, this would mean the off hand would be used for adjusting the position of the thumb, and locking the fingers. Despite my focus on minimizing this, I think this would still be a worthwhile compromise whenever situations to lift something heavy in that way arise.

2) Actually with the servos I am using being continuous rotation types, they do have the ability to alter speed/direction but even at the highest speed this is not very fast due to the high torque ratio. Based on a past prototype that used DC motors, I was also trying to avoid this because using DC motors with an Arduino means having to use motor driver carriers for every 1 or 2 motors which I found to be a hassle in terms of the volume taken up by the board and extra wires too.

3) This is definitely an area of concern for me, especially with you mentioning this being the fatal flaw of the Hackberry which I was not previously aware of. I will take this into account as I am testing the arm and will make the changes I specified if necessary--thanks for emphasizing this.

4) Actually now that I think about this, adding a fail safe in addition to the current design would not be that difficult considering that the I need to create a "weakest point" somewhere in that gear train/servo flex shaft system. Because these components are going to be 3D printed anyways, I could just have the gear train's driving gear be 3D printed using maybe 5% or less infill such that if enough stress is applied, then the gear would break before any other parts do. The only drawback with this of course is that unlike the popping knuckle joints/breakaway pins you mentioned, this would not be re-settable without having to print that gear again.


Bhargav Parthasarathy Mon 11 Feb 2019

Hi everyone, it has been a bit since I have posted an update after my proposal was approved so I wanted to mention a couple things:

  • As stated in my proposal (or in a reply, I can't remember which), I will be documenting my progress for anyone to follow at: https://bhargavp225.wixsite.com/mysite I know the name "The HAND-icap Project" sounds kind of corny so I might change that once I think of something better.
  • After getting approved for funding and submitting an Open Collective expense request, the $452.00 was payed out to me and I have that money now so I will begin ordering parts and taking further action soon (see update on website for more info)

Again thank you all for the comments and support, and be sure to check the website link for all further updates.


Yoav Medan Mon 11 Feb 2019

How about Handy-Hand



Bhargav Parthasarathy Tue 17 Mar 2020

Hi everyone, I know it has been a while since I last posted here on the E-nablio forum and in the updates section of my project website. I wanted to provide an update though on how things have been going, and I recently emailed Mr. Schull about this too and so I'll paste that email here because I think it covers my thoughts:

"Hi Mr. Schull,

Firstly, this is going to be a somewhat long email. I know it has been a while since I last spoke to you, but I wanted to talk to you about the status of my project and some steps I want to take. You may recall that about a year ago, I received a mini-grant through the e-NABLE foundation for my project to build a novel transradial prosthetic arm. At this point, however, having not yet reached the goals I set out to accomplish, I wanted to talk to you about returning the grant money I was given.

I am saying this because, if I can speak honestly, the urge I keep feeling to finish this project and how it has conflicted with the commitments I have to school and extracurriculars has been very frustrating for me, and I have felt increasingly guilty about accepting the grant money but not yet delivering what I promised to the community. I apologize for this.

To give a recap and status update on my progress, originally with the backing of the community and the time to work on the project I progressed for a while and reached a decent level of completion with the mechanical stage of the project completed. Since then, however, the weight of my college courses and other extracurriculars has been very heavy on me to the point that my progress with this project became very slow.

To date, since completing the mechanical assembly I have done a very small amount of testing concerning control of the hand using an Arduino Uno, but I wouldn't really say I have ventured into the electronics integration stage yet. There is one other objective that I was not able to fulfill as well: my goal to document my progress in an open source format. Again, this was due to my inability to dedicate a sufficient amount of time to do this correctly. Although, I did briefly share my CAD and STL files directly from my google drive for anyone interested to use, but this was careless of me to do without any creative commons license protection. Even with the updates to my website, at some point these became very infrequent as I had felt there was very little to update on without repeating that I had yet another setback.

As far as the future of this project is concerned, my other commitments unfortunately have not slowed in terms of my involvement in them and so it is still difficult for me to promise a certain amount of progress in a certain amount of time. However, I know that at some point I am going to finish this project just because of how much time I have already invested in this, and because I am still motivated to reach the goals I have set. Again though, I understand that I cannot just take my sweet time because I am using money that was given to me with the expectation of completion by a certain time. I hope you can understand why it has been difficult for me to complete this project in the timeline I originally promised. This is why I think the right decision for me should be to return the grant money.

Hopefully sometime in the future after I have completed my project, I hope you and/or the community may be open to the idea of possibly allowing me to reapply for the grant money again after I have proven results and have shared the project on an open source platform. If you and/or the community do not feel the same way about this though, I would understand completely. I was also planning on sharing this in the E-nablio forum for the users who originally backed my project to see, but I wanted to hear your thoughts first. Thank you for your trust.

Best regards,

Bhargav Parthasarathy"

Anyways, I wanted to let you all know that I just returned the grant money ($438.76) I was given via a donation to the e-Nable fund and that Mr. Schull was very understanding of my situation so I appreciate that as well. As the email above mentions, I will be sure to get back to you all when I have some results to share that I hope will be useful for the community's progress. Thank you all for your support.