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....

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.

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!

A Thumb-up for an e-thumb

BR/Yoav

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.

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.

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:
https://docs.google.com/spreadsheets/d/1ue6cWVnkKPzd1UW-p4PodXCmFX0dN42_Daxiv5_ecCE/edit?usp=sharing
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.

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.

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).

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.

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.

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.

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!

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.

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.

How about Handy-Hand

BR/Yoav

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.