Table of Contents
Team Vision for Subsystem-Level Design Phase
- The purpose of this phase was to further develop the critical subsystems identified in the previous phase and to assess the individual feasability of each of them.
- The P16061 Design team researched products for use in their prototype and re-evaluated the risks of the project as a whole.
Feasibility: Prototyping, Analysis, Simulation
Our torque requirement was determined by testing done on e-NABLE hands in the lab, by using a digital fish scale to measure the maximum force needed to keep the hand in place. The length was measured with a ruler and extends from the turning hinge to the end of the gauntlet. Our approximate torque requirement was derived by multiplying the largest torque value by a factor of 3, to account for the uncertainty of our small sample size.
http://www.amci.com/tutorials/tutorials-stepper-vs-servo.asp - Great article for explaining the differences between stepper and servo motors.
The summary of the article is that servo motors use fewer magnetic loops to generate their torque, which minimizes the force decay as you increase speed. However, this means that they have a lower maximum torque than stepper motors and they are more prone to degradation since those coils are subjected to a larger electric load. Stepper motors use ~10x the number of coils, 50 to 100 compared to servo's 4 to 12. This allows them to generate more force at low speeds without placing large current loads on the coils. Additionally, servo motors are designed with an encoder in mind, so they cannot sense their own position and need to receive feedback from it in order to move. Stepper motors are pre-programmed to have an evenly spaced, finite number of angle configurations (called steps) that they can cycle through. As a consequence, they also have no need for an angle sensor since the input angle is already where the stepper should be positioned.
Our team chose stepper motors because they don't require an additional angle sensor, the lack of high-speed movement doesn't effect us, and they cost less than servos for comparable torque values.
Below are Pugh Charts and a Specifications Chart for the stepper motors we chose to compare.
Our team chose the MPJA Nema 23 motor because the larger torque from the Robotshop Nema 17 is unnecessary, while the increase in price is very much necessary
Our team tested a variety of clamps at the local Home Depot to determine which would hold the prosthetic stationary without causing any damage.
Here is a link to our document, explaining in detail the pros and cons of each clamp choice.
Our team selected the trigger clamp (the 3rd picture) because of the padded ends, which allow enough force to be applied to keep the hand steady while reducing the risk of damage to it.
Arduino was selected during the last phase, and our decision hasn't changed. The open source software, and compatability with other commonly used applications (such as Excel) make it perfect for satisfying our customer requirements
Here is a link to the Arduino processor our team will be buying.
There were multiple ideas for how to display the data through Arduino:
- LED Display
- SD Card
- LabView Interface
- "Graph" Function
- "GoBetwino" Function
There were two ideas for the “External”
option: LED Display and SD Card. The LED Display would
allow for live readings, but would only consist of
numbers, which would not be very useful for a lot of
data; graphs would be much more meaningful. The SD Card
would be able to save the information to later be put
into the computer, but it was decided that the computer
would be the power source for the entire apparatus.
Therefore, it would make little sense to export data to
an external drive when it is already attached to a
The LabVIEW Interface with Arduino idea was interesting
because not only would it allow for displaying data
through LabVIEW, but it would allow for programming in
LabVIEW. This was a positive aspect for the team because
the majority of us had experience with LabVIEW. But, this
was a downside because LabVIEW is a very expensive
program that we should not expect the members of the
e-NABLE community to have access to or knowledge of.
“Graph” would be a very useful function for
this apparatus, but it does not allow for enough user
input. As expected, it outputs a graph that allows the
user to see what was just computed, but it does not allow
for further data processing.
PLX-DAQ, or Parallax Data Acquisition tool, is an open source add-in for Microsoft Excel. It would allow for data acquired from the Arduino to be sent into a spreadsheet, which can be processed however the user sees fit after the fact through the basic functions of Excel. Similarly, “GoBetwino” is a function that would allow for data to be sent from Arduino to Excel. At this time, we are unsure which one is the better option, but the consensus is that exporting data to Excel is the best option for the method of how to display data.
Data Collection Feasability
During last design phase, our team narrowed down the selection of sensors to two options of either finger sensors or a strain gauge load cell.
A Strain Gauge Load Cell was selected as the best choice because of its superior cost, accuracy, and ease of programming. However, since FSR’s are cheap and easy to use they will be tested as a backup plan.
Multiple types of load cells were then researched and compared.
Link 1 - Single Point Load Cell
Link 2 - S-Beam Load Cell
Link 3 - Miniature Load Cell
Link 4 - Single Point Load Cell
The Single Point Load Cell found in Link 4 was chosen as the best possibility due to its combination of high accuracy and low cost. Below are more details on this Load Cell.
Drawings, Schematics, Flow Charts, etc.
Revised Model after considering issues with load cell placement.
The original pictures have been compiled here
Software Flow Chart
Bill of Materials (BOM)
Our Bill of Materials, along with a picture illustrating what each part is and where it will be on the prototype. Link to the full excel spreadsheet here
Design Review Materials
Plans for next phase
- During the next phase, our team plans to begin ordering parts from our BOM to construct our prototype.
- We will also pursue borrowing hands from e-NABLE and other sources to collect a large sample size. We will also begin programming our Arduino controller, since we foresee issues with this step in particular.
- As a group, we will discuss the feasibility of including another force sensor on the gauntlet to measure the force applied to it.
- Lastly, we will continue updating our risks for both the entire projects and our systems and sub-systems.