You are on page 1of 37

Assistive Wearable Hand Exoskeleton Group 5

Verification and Validation Revision 1.0

Member Name
David Viscomi Rahul Bhagat Nelson Lebre Louidgie Theoret David Findlay Hao Zhang

Student ID
1055349 1071818 0952362 1060755 1052075 0842755

Table of Contents
1 2 3 4 5 Revisions References List of Figures List of Tables Introduction 5.1 Verification and Validation 5.2 Wearable Hand Exoskeleton Verification Tests 6.1 Communication Interface Test 6.1.1 Structural Code-Based Testing Procedure 6.1.2 Test 001 6.1.3 Test 002 6.1.4 Test 003 6.1.5 Test 004 6.1.6 Test Summary 6.2 Linear Actuator Positioning Control Test 6.2.1 Structural code-based testing procedure 6.2.1 Recorded Data 6.3 Force Sensor Test 6.3.0 Structural code-based testing procedure 6.3.1 Test 001 6.3.2 Test 002 6.4 Mechanical Design Tests 6.4.1 Range of Motion Test 6.4.1 Structural Integrity Test 6.5 System Test Validation

Revisions
Version 0.1 Date 2014.02.19 Authors David Findlay, Hao Zhang, Nelson Lebre, Rahul Bhagat, Nelson Lebre, Louidgie Theoret David Findlay, Hao Zhang, Nelson Lebre, Rahul Bhagat, Nelson Lebre, Louidgie Theoret Louidgie Theoret, Rahul Bhagat, Hao Zhang Details Introduction, Validation, Verification Outline, Verification Tests

0.2

2014.02.22

Validation, Verification Tests

1.0

2014.02.23

Formatting, Verification: System Tests

References
1. I. Sommerville, Software Engineering. New York: Pearson/Addison-Wesley. 2. Software & Systems Engineering Standards Committee of the IEEE Computer Society, A Guide to Project Management Body of Knowledge, 4th ed. New York: Project Management Institute Inc., 2013.

List of Figures
(Left) Cylindrical Grip Action. (Right) Precise Pinch Action. Wearable Hand Exoskeleton Functioning Prototype. Linear Actuator fully retracted still allows hand to feel comfortable. Cylindrical grip reaching mechanical limit. After applying ~49.9N force perpendicular to the surface, no deformation occurred. Note: Scale tared with glove on it to provide friction. Pulley-based tendon actuation of human finger. Rapid-Prototyped Model.

Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. Figure 6. Figure 7. Figure 8.

List of Tables

Table 1. Structural code-based checklist for communication interface. Table 2. Test case 001 for communication interface. Table 3. Test case 002 for communication interface. Table 4. Test case 003 for communication interface. Table 5. Test case 004 for communication interface. Table 6. Test Case Summary for Communication Interface. Table 7. Structural code-based checklist for Linear Actuator. Table 8. Test case 001 for Linear Actuator Table 9. Recorded data for Linear Actuator test. Table 10. Structural code-based checklist for force sensor. Table 11. Test case 001 for force sensor. Table 12. Test case 002 for force sensor.fofor Table 13. Recorded data for force sensor. Table 14. Recorded data for force sensor. Table 15. Test case 001 for mechanical test. Table 16. Test case 002 for mechanical test. Table 17. Test case 001 for system test. Table 18. Validation.

5
5.1

Introduction
Verification and Validation

These are independent quality control processes performed with the purpose of checking that a system meets specifications and that it fulfills its intended purpose safely. The PMBOK guide1 , a standard adopted by IEEE, defines them as follows: Verification is the evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. Validation is the assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. A bottom up approach was taken in effort to perform integration testing. Every control module is tested in isolation. Multiple tests were done per module to ensure working behaviour in isolation under different constraints and inputs. Each test is labelled with a unique test case ID. The control modules that require software testing were subjected to a general structure code-based testing procedure. This was done to mitigate any sources of error in the software itself. These modules include: force sensor data acquisition, linear actuator position control, and messaging interface. Although elaborate effort was done to scrutinize the code, the possible errors that went undetected does not guarantee that they are non-existent. System testing includes testing recovery, stress, and performance of the device.

Software & Systems Engineering Standards Committee of the IEEE Computer Society, A Guide to Project Management Body of Knowledge, 4th ed. New York: Project Management Institute Inc., 2013.
1

5.2

Wearable Hand Exoskeleton

The Wearable Hand Exoskeleton concept is a wearable robot mechatronics system with a physical interface that permits intelligent transfer of mechanical power to enable the user to perform a cylindrical grip action or precise pinch action.

Figure 1. (Left) Cylindrical Grip Action. Figure 2. (Right) Precise Pinch Action. The wearable system is designed to match the shape and specific functions of the human hand. The system is made of various segments and joints controlled by actuation while being externally coupled to the forearm and palm. The Wearable Hand Exoskeleton system is designed to fulfil two main objectives: 1. Be able to understand and comply with user intent. 2. Be able to maintain a firm and steady grip on the object.

Figure 3. Wearable Hand Exoskeleton Prototype. Wearable Hand Exoskeleton consists of an externally coupled mechanical design that is sewn to the dorsal side of the palm and wrist. A linear actuator is connected to the mechanical structure and its linear motion will translate into movement of a digit of the hand.

Verification Tests

The verification process was carried out using the bottom up testing method. Each control module is tested in isolation. The control modules include: communication interface, linear actuator positioning control, and force sensor data acquisition. This unit testing is followed by system testing.

6.1

Communication Interface Test

6.1.1 Structural Code-Based Testing Procedure This checklist is a general procedure implemented to mitigate sources of error in the software. Each static analysis check was done with scrutiny in order to reduce the

probability of unexpected errors occurring. If a possible fault is not detected, we cannot conclude that the fault is non-existent. However, this procedure allows the system to approach fault tolerance with greater confidence.

Fault Class Data Faults

Static Analysis Check Variable used before initialization Variable declared but never used Variable assigned twice but never used between assignments Possible array bound violations Undeclared variables Interfering Registers Timer/Counter Overflow

Detected and Corrected

Undetecte d

Register Initialized interrupt Initialized Control Faults Unreachable code Unconditional branches into loops Input/Output faults parameter type mismatch parameter number mismatch Non-usage of the results of functions uncalled functions and procedures Input/Output Initialized Message Lost Storage managements Unassigned pointers faults Pointer arithmetic

Table 1. Structural code-based checklist for communication interface

6.1.2 Test 001 The premise of this test is to test basic communication between the Master and slave CPU.A byte value is loaded onto both master and slave, the slave has a comparator between the loaded byte value and what it receives on the bus. A pushbutton is pushed which tells the master to send the byte to the slave. If the byte that is preloaded in the slave is the same as the byte it receives on the bus, it lights an LED. Date of Test Test Case ID Revision Number Name of tester Safety Precautions and Hazard Analysis February 20 2014 001 0.0 David Viscomi The communications lines connecting the MCUs must be securely fastened to avoid miscommunication. If there is a break in communication the child MCUs would function without being monitored. Analysis of the synchronous MCU communication can be determined by assigning a test byte in the sending and receiving MCUs. If the receiving MCU does not receive a message which is identical to the test byte, it will not indicate that a correct message has been sent. This is a simple yet effective way of guaranteeing a proper communication protocol. Pass

Calculation and analysis of results

Pass/Fail

Table 2. Test case 001 for communication interface.

6.1.3 Test 002 The premise of this test is to test sequential messages from master to slave. The procedure is the same as test ID 001, with the addition that the Slave MCU LED indicator is set to toggle on or off after every successful receive of a message from a master. Date of Test Test Case ID Revision Number Name of tester Safety Precautions and Hazard Analysis Calculation and analysis of results Pass/Fail February 20 2014 002 0.0 David Viscomi Refer to Safety Precautions and Hazard Analysis in Test case 001 refer to Calculation and analysis of results 001 Pass

Table 3. Test case 002 for communication interface.

6.1.4 Test 003

The premise of this test is to test communication between a Master and multiple slaves. The procedure is the same as Test Case ID 002 except now there are multiple slaves on the bus. We now have a unique address byte which is assigned to each slave, we program the master to send that byte. If a slave receives its address on the bus, it toggles its indicator ID. If it does not recognize the address, it does nothing.

Date of Test Test Case ID Revision Number Name of tester Safety Precautions and Hazard Analysis Calculation and analysis of results Pass/Fail

February 20 2014 003 0.0 David Viscomi refer to Safety Precautions and Hazard Analysis in Test case 001 refer to Calculation and analysis of results 001 Pass

Table 4. Test case 003 for communication interface.

6.1.5 Test 004

The premise of this test is to test global communication between a Master and multiple slaves. The procedure is same as Test Case ID 003 except now we send a global message to all slaves, so when a pushbutton is pressed, the Master CPU sends a message that is meant for all Slave CPUs. They should all light their LED indicators.

Date of Test Test Case ID Revision Number Name of tester Safety Precautions and Hazard Analysis Calculation and analysis of results Pass/Fail

February 20 2014 004 0.0 David Viscomi refer to Safety Precautions and Hazard Analysis in Test case 001 refer to Calculation and analysis of results 001 Pass

Table 5. Test case 004 for communication interface.

6.1.6 Test Summary The test cases are summarized in this section. The expected outputs are compared to actual outputs. Test Case ID Input Expected Output and Acceptance Criteria Led lights up on the slave Led light on slave toggles with each new message it receives If the master sends the address of a certain slave, only that slave will light its indicator LED Actual Output

001 002

Push button Interrupt Push button interrupt

Led lights up on the slave Led light on slave toggles with each new message it receives when the master sends the address of a certain slave, only that slave will light its indicator LED

003

Push button interrupt

004

Push button interrupt

If the master sends All slaves light their a global message, all indicator LEDs of the slaves should light their indicator LED

Table 6. Test Case Summary for Communication Interface.

6.2

Linear Actuator Positioning Control Test

6.2.1 Structural code-based testing procedure This checklist is a general procedure implemented to mitigate sources of error in the software. Each static analysis check was done with scrutiny in order to reduce the

probability of unexpected errors occurring. If a possible fault is undetected, we cannot conclude that the fault is non-existent. However, this procedure allows the system to approach fault tolerance with greater confidence.
Fault Class Data Faults Static Analysis Check Variable used before initialization Variable declared but never used Variable assigned twice but never used between assignments Possible array bound violations Undeclared variables Control Faults Unreachable code Unconditional branches into loops Input/Output faults parameter type mismatch parameter number mismatch Non-usage of the results of functions uncalled functions and procedures Detected and corrected Undetected

Storage managements faults

Unassigned pointers

Pointer arithmetic

Table 7. Structural code-based checklist for Linear Actuator. 6.2.1 Test 001

Linear actuator is controlled in steps of 5mm starting from 0mm and extending fully to 50mm. Every incremental movement is recorded using a mm-scale. The purpose of this test is determine the accuracy of position control. Date of test Revision tested Test case ID Name of tester Acceptance criteria Safety precautions and hazard analysis 20/02/2014 0.0 001 David Findlay and Hao Zhang The control is acceptable if the error does not exceed 3mm. The sensor is isolated from the electrical environment by insulating the wires using heat shrink tubing. The linear actuator has a stall current of 450mA. This current is dangerous for human beings and therefore careful circuit isolation was done to prevent electrical shock. Refer to Table 9 for the recorded data. The maximum error is +3mm from the desired position. Therefore, this falls within the acceptance criteria. The error increases as the position from the origin increases. The smaller the object, the less accurate the positioning. A possible solution to increasing the accuracy of the linear actuator is to use a 6V power supply to the linear actuator rather than 5V. The data sheet advises the use of 6V power supply; however to reduce power complexity in the control circuit, a 5V power supply was used. Pass

Calculation and analysis of results

Pass/Fail

Table 8. Test case 001 for Linear Actuator

6.2.1 Recorded Data The expected position is compared to the measured position in 5mm increments to determine a maximum error in positioning. A sample calculation for 35mm is as follows: Error = |Expectedposition measuredposition| = |3mm 37mm| = 2mm

expected position (mm) 0 5 10 15 20 25 30 35 40 45 50

measured position (mm) 0 5 11 16 21 27 33 37 42 48 53

Error (mm) 0 0 1 1 1 2 3 2 2 3 3

Table 9. Recorded data for Linear Actuator test.

6.3

Force Sensor Test

6.3.0 Structural code-based testing procedure This checklist is a general procedure implemented to mitigate sources of error in the software. Each static analysis check was done with scrutiny in order to reduce the

probability of unexpected errors occurring. If a possible fault is not detected, we cannot conclude that the fault is non-existent. However, this procedure allows the system to approach fault tolerance with greater confidence.
Fault Class Data Faults Static Analysis Check Variable used before initialization Variable declared but never used Variable assigned twice but never used between assignments Possible array bound violations Undeclared variables Control Faults Unreachable code Unconditional branches into loops Input/Output faults parameter type mismatch parameter number mismatch Non-usage of the results of functions Detected and corrected Undetecte d

uncalled functions and procedures Storage managements faults Unassigned pointers

Pointer arithmetic

Table 10. Structural code-based checklist for force sensor. 6.3.1 Test 001 The force sensor is subjected to a loading test. Starting with 0N force applied and gradually applying a force to the sensor. Data is recorded every 20ms by the MCU. Date of test Revision tested Test case ID Name of tester Acceptance criteria Safety precautions and hazard analysis Calculation and analysis of results 20/02/2014 0.0 001 David Findlay and Hao Zhang The readings show an increase in voltage values. The sensor is isolated from the electrical environment by insulating the wires using heat shrink tubing. Refer to table 13 for the recorded data.The voltage readings show that the load increases from 0N to 2.717498N in the first 20ms and then to 4.408602N in the next 20ms. The voltage readings remains approximately the same for the remaining time. The test shows that the sensor is very sensitive and has a low range of force. The criteria is met. Pass

Pass/Fail

Table 11. Test case 001 for force sensor.

6.3.2 Test 002 The force sensor is subjected to an unloading test. Starting with 20N force or more and gradually releasing the force to the sensor. Data is recorded every 20ms by the MCU. Date of test Revision tested Test case ID Name of tester Acceptance criteria Safety precautions and hazard analysis Calculation and analysis of results 20/02/2014 0.0 002 David Findlay and Hao Zhang The readings show a decrease in voltage values. The sensor is isolated from the electrical environment by insulating the wires using heat shrink tubing. Refer to table 14 for the recorded data.The voltage readings show that the force starts at 4.75073N and remains approximately the same until 80ms where it drops to 0N. This shows the sensitivity of the resistor is high. The criteria is met. Pass

Pass/Fail

Table 12. Test case 002 for force sensor.

7.3.3 Recorded Data The table shows the data recorded for test case 001 for force sensor test.

Time (ms) 0 20 40 60 80 100 120 140 160 180

voltage reading (V) 0 2.717498 4.408602 4.565005 4.59433 4.618768 4.643206 4.667644 4.677419 4.687194

Table 13. Recorded data for force sensor.

The table shows the data recorded for test case 002 for force sensor test.

Time (ms) 0 20 40 60 80 100 120 140 160 180

voltage reading (V) 4.750733 4.726295 4.760509 4.692082 0 0 0 0 0 0

Table 14. Recorded data for force sensor.

6.4

Mechanical Design Tests

6.4.1 Range of Motion Test The table below tests the maximum and minimum extent of movement that the mechanical hand design can obtain. Date of Test Revision tested Test Case ID Name of tester Acceptance Criteria February 20, 2014 0.0 001 Nelson Lebre, Rahul Bhagat, Louidgie Theoret The mechanical hand should not interfere with the users natural hand movement (not pulling fingers back and not pushing fingers past the palm) There are three provisions for safety in this test: 1. The maximum extent of the mechanical design movement is coded in software to 55% of the maximum extent of the actuator (27.5mm). This is the limit when the mechanical design is curled to the extent of range of the human hand. In addition to this, to prevent unnatural backward motion of the finger, a software implemented limit of 2.5% of the linear actuators distance is set to a comfortable rest state. Even at 0% of the linear actuators distance, the finger will still be in a comfortable state. 2. A safety feature is implemented into the mechanical design that prevents the actuator from moving past an apriori set limit. This limit occurs well before unnatural forward motion of the finger. Mechanical hand curls around object similarly to a human hand. Once the user has a full grasp of the object, the mechanical design focuses the linear actuator force at the tips of the fingers providing the assistive grasping force needed Failed: UNTESTED; awaiting ethics approval

Safety Precautions

Calculation and analysis of results

Pass/Fail

Table 15. Test case 001 for mechanical test.

Figure 4. Linear Actuator fully retracted will allow hand to feel comfortable.

Figure 5. Cylindrical grip reaching mechanical limit.

6.4.1 Structural Integrity Test This table illustrates the amount of stress the mechanical system can receive by grasping an object before deforming. Date of test Revision tested Test Case ID Name of tester Acceptance criteria Safety precautions and hazard analysis Calculation and analysis of results February 20, 2014 0.0 002 Nelson Lebre, Rahul Bhagat, Louidgie Theoret The mechanical hand must be able to squeeze with a 12N (max force of actuator) force before deforming. External force sensor is used to measure the applied force between the object and mechanical system. F=ma =(5.088kg)*(9.81m/s2) =49.91N The linear actuator applies a parallel force to the links. The mechanical links can withstand a force of at least 49.9N which is well beyond the range of operation (so the links used to transfer forces from linear actuator to finger will not shear). Refer to figure below. Pass/Fail Pass

Table 16. Test case 002 for mechanical test.

FIGURE 6. After applying ~49.9N force perpendicular to the surface, no deformation occurred. Note: Scale tared with glove on it to provide friction.

6.5

System Test

The system behaviour is tested by trying to grasp and then release a cylindrical object.

Date of test Revision tested Name of tester Acceptance criteria

23/02/2014 0.0 Hao Zhang, Louidgie Theoret The following are a list of steps for an acceptable test run: 1. Understanding user intent to initiate grasping action. 2. Successfully grasping the object a. Completely enclose object b. Grip firmly without deforming object 3. Delivering adequate grip to allow picking up from surface. 4. Understanding user intent to release grasping action. 5. Release object on command Refer to all safety precautions seen in other tests.

Safety precautions and hazard analysis Calculation and analysis of results Pass/Fail

Observations: N/A
Failed: UNTESTED; awaiting ethics approval

Table 17. Test case 001 for system test.

Validation

The Wearable Hand Exoskeleton is a robotic device whose mechanical design is located in close proximity to the digits of the human hand. Ideally, the linkages of the device are designed such that they follow the users movement. The linkages are controlled by programmable actuation system that exert force to move the finger. The most important features to be considered are listed below: Maximizing matching between human reachable workspace and robot workspace, to ensure operation ease and to maximize range of motion. Equalizing force distribution over the finger, to distribute force of actuation and create a comfortable device that does not overload any single phalanx of the finger. Dr. Peter Keir, Associate Professor of Kinesiology at McMaster University was consulted to learn about the nuances of the motion of a human hand. He highlighted several key features of the design of a human hand that informed design decisions. Dr. Keir suggested exploring a design mounted on either the dorsal or palmar side of the hand. He also suggested mimicking the hands natural mechanism for finger flexion and extension. One way to accomplish this is with a pulley-based system that would operate with servo motors mounted on the forearm. This would entail creating a single phalanx hand exoskeleton, where the pulleys pull on only the distal phalanx (fingertip) via cables. This would drastically reduce the available workspace due to interference with cables that would run along the palm of the hand.

Figure 7. Pulley-based tendon actuation of human finger. An alternate approach was chosen, which involved a rigid link multi-phalanx hand exoskeleton in which different forces are exerted on each phalanx of the finger. This was achieved by a quasi-anthropomorphic design that is morphologically similar to the kinematics of the finger. This would fit the requirements of optimal matching of the mechanism and human hand workspace. The design developed only differs slightly in length of links to allow mounting on the dorsal side of the hand. Dr. Gary Bone, Professor of Mechanical Engineering at McMaster University, was consulted for determining the ideal mechanical design stiffness and actuator selection criteria. Based on this discussion, initial rapid prototyped models were created from ABS plastic. This model

was not a good representation of the system because the 3D printers used did not have a high enough resolution to print all parts appropriately.

Figure 8. Rapid-Prototyped Model. Subsequently, a stiff steel link based prototype design was constructed using toy engineering construction kits and a specially modified kevlar glove to maximize movement. This steel based multi-phalanx design is an ideal setup because it distributes force from the actuator equally over all the phalanges of the finger at the point of attachment. Dr. Gary Bone also discussed the sensor placement on the exoskeleton hand. He suggested having sensors measuring the users motion and another sensor measuring the force being applied to the object. Without a sensor measuring the force against the object the group won't know how much force is being applied which may result in deforming the object or not applying enough force.

The following table lists the requirements and respective reasonings to justify if the system designed meets them or and suggests if further improvements are needed.

REQUIREMENTS PERFORMANCE REQUIREMENTS Portability Repairability Robustness

How the system meets the requirements

This requirement will no longer be met The structure of the mechanical hand is assembled by using easily replaceable parts Software System: The software implementation will allow the system to grasp varying diameters. This will be done by allowing the actuator to extend until the hand comes in contact with the object. At this stage the system fine adjusts to firmly grasp the object. Communications, not yet met: The Supervisor MCU monitoring the values of each child MCU allows for greater safety by continuously checking all the child processor values against acceptable ranges. All errors can be checked by the Supervisor which can determine what safety state the system should enter.

Reusability Reliability

The device is not made of materials that are one-time-use only (disposable) Reliability would be achieving consistent behaviour. There are four measures taken to ensure reliable performance: Structural integrity: Mechanical design uses strong steel parts Linear actuator: breaks down after 1000 hours of 20% duty cycle Force Sensor: gives reliable readings as long as calibrated at the start before use - and it is secured properly Code: confirmed by the tests performed during verification

SAFETY REQUIREMENTS

Does no harm to object being grasped

A force sensor is present to detect contact with the object being grasped and stops the grasping motion Same as above Software Implementation: Limited the linear actuators travel distance within code itself Mechanical Implementation: Extending: Goes into a lock-stage when the linear actuator overextends reaching a mechanical limit (collinearity occurs with links causing motion to cease) Retracting: Not yet met Future solution: retracting the linear actuator will be limited mechanically by customizing the links to lock after a certain distance of being retracted The exoskeleton is mounted on an insulating glove Linear actuator is fixed above hand allowing sufficient distance between glove/hand and linear actuator to prevent contact Used a Breadboard to safely and accurately connect the circuit preventing any wires from intentionally coming in contact

Dont deform object by squeezing too hard. Active mitigation against and deals with forced flexing and extending fingers beyond natural motion range.

Active mitigation against and deals with Electrocution elegantly. Active mitigation against and deals with Overheating elegantly.

Active mitigation against and deals with short circuits elegantly.

UNDESIRED EVENT HANDLING Gripping too tightly. Force Sensor is present to detect contact with the object being grasped and stops grasping motion Not fully met, sensitivity of force sensor that is used for the fingertip stops at very low readings Future solutions: mechanical dampener between stop

Gripping with inadequate strength.

Order of normal operation not followed.

sensor and object software or hardware high-pass filter

Not yet met Future solution: Implementing a supervisor chip to overlook operation of individual microprocessors

Flexing and extending fingers beyond natural Software Implementation: motion range. Limited the linear actuators travel distance within code itself Mechanical Implementation: Extending: Goes into a lock-stage when the linear actuator overextends reaching a mechanical limit (collinearity occurs with links causing motion to cease) Retracting: Not yet met Future solution: retracting the linear actuator will be limited mechanically by customizing the links to lock after a certain distance of being retracted Overheating. Linear actuator is fixed above hand allowing sufficient distance between glove/hand and linear actuator to prevent contact Used a Breadboard to safely and accurately connect the circuit preventing any wires from intentionally coming in contact Any feedback error resulting in the linear actuator to over extend or retract will be limit to the range in which the mechanical system can move. As well, software restricts the linear actuators motion

Sudden release of energy due to a short circuit.

Inappropriate feedback of action.

REQUIREMENTS THAT MAY CHANGE Source of power for exoskeleton Include grasping of non-cylindrical objects This is now a requirement that cannot change: A power supply will be used Not yet met

Pinching is possible if a distributed system is used rather than centralized system (each finger/set-of-fingers has its own grasp sensor) Diameter range of cylindrical object able to grasp This requirement is now invalid because it conflicts with the requirement that the device must accommodate medium-sized hands (hand-size determines range of radii) This is now a requirement that cannot change: a specific linear actuator is used L12-50-100-12-I Linear Actuator Gripping force needed to hold objects This is now a requirement that cannot change: a specific linear actuator is used L12-50-100-12-I Linear Actuator REQUIREMENTS THAT MAY NOT CHANGE Device will accommodate medium-sized hands. A medium sized glove was used Length: 22.9 centimeter Width: 10.2 centimeter Height: 25 millimeters ASIN: B0062320KM Device will be for the right hand. Device must be easy to unequip. The right-hand glove was used from above The system is incorporated onto a glove where it can be easily equipped or unequipped by the user Force Sensor is present to detect contact with the object being grasped and stops grasping motion The device operates on PWM so when there is no power it will stop immediately Software Implementation: Limited the linear actuators travel distance within code itself Mechanical Implementation: Extending: Goes into a lock-stage

Grasping speed

Device must not harm object being grasp.

Device must shut off if there is electrical failure or overheating. Device must stop movement action if it is beyond natural motion range.

when the linear actuator overextends reaching a mechanical limit (collinearity occurs with links causing motion to cease) Retracting: Not yet met Future solution: retracting the linear actuator will be limited mechanically by customizing the links to lock after a certain distance of being retracted Device must apply all the power needed to grasp the object. This requirement will no longer be met The device has always meant to be assistive, not replacing regular hand motion

NORMAL OPERATION Grasping motion initiated by user. Not fully met A sensor can be pressed to initiate grasping motion, but it is not mounted on system yet Device begins assistive force. System is programmed to begin grasping motion once a signal is received from sensor Not fully met, sensitivity of force sensor that is used for the fingertip stops at very low readings Future solutions: mechanical dampener between stop sensor and object software or hardware high-pass filter After action is complete, system initiates release motion. Edit: After action is complete, system initiates release motion on users request Not fully met A sensor can be pressed to initiate release motion, but it is not mounted on system yet Device releases force applied allowing to System is programmed to begin release

Device grasps object securely without squeezing too hard.

loosen grip. Table 18. Validation.

motion once a signal is received from sensor