P16061: e-NABLE Hand Test Rig
/public/

Subsystem Design

Table of Contents

Team Vision for Subsystem-Level Design Phase

Feasibility: Prototyping, Analysis, Simulation

Motor Feasability

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.

public/Systems Level Design Documents/Subsystem/ForceTesting.JPG public/Systems Level Design Documents/Subsystem/ForceValue.JPG


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.

public/Systems Level Design Documents/Subsystem/ServoValue.JPG


Below are Pugh Charts and a Specifications Chart for the stepper motors we chose to compare.

public/Systems Level Design Documents/Subsystem/MotorPugh1.PNG public/Systems Level Design Documents/Subsystem/MotorPugh2.PNG public/Systems Level Design Documents/Subsystem/MotorValue.PNG

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


Clamp Selection

Our team tested a variety of clamps at the local Home Depot to determine which would hold the prosthetic stationary without causing any damage.

public/Systems Level Design Documents/Subsystem/Clamp C.PNG public/Systems Level Design Documents/Subsystem/Clamp Bar.PNG public/Systems Level Design Documents/Subsystem/Clamp Trigger.PNG public/Systems Level Design Documents/Subsystem/Clamp SmallTrigger.PNG

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.


Controller Selection

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

LED Display

SD Card

SD Card

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

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.

public/Systems Level Design Documents/Subsystem/FingerStrainVennDiagramR1.PNG

public/Systems Level Design Documents/Subsystem/SensorPugh.PNG

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.

public/Systems Level Design Documents/Subsystem/LoadCellComparison.PNG

Link to Source Page

public/Systems Level Design Documents/Subsystem/LoadCellPugh.PNG

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.

public/Systems Level Design Documents/Subsystem/FinalStrainGaugeSelection.PNG

Drawings, Schematics, Flow Charts, etc.

Solidworks Model

Revised Model after considering issues with load cell placement.

The original pictures have been compiled here


Assembly of Model Base

Assembly of Model Base

Assembly of Strain Gage Base

Assembly of Strain Gage Base

Complete Testing Apparatus

Complete Testing Apparatus

Software Flow Chart

public/Detailed Design Documents/Software/CodeFlowChart.jpeg

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

public/Detailed Design Documents/BOM.PNG public/Systems Level Design Documents/Subsystem/SolidworksTotal.PNG

Design Review Materials

Plans for next phase

public/Systems Level Design Documents/Subsystem/PlanningTable.PNG


Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Subsystem Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Integrated System Build & Test with Customer Demo | Customer Handoff & Final Project Documentation