M.E.C.H: Motorized EMG-Controlled HandThe system will provide two forms of feedback to the user:...

University of California, Santa Cruz

M.E.C.H: Motorized

EMG-Controlled Hand Quarter One Report

Revision 1.1: 01/09/2014

M.E.C.H. | Q1 Report

1

Table of Contents

Table of Contents .......................................................................................................................................... 1

Team Members ............................................................................................................................................. 2

Abstract ......................................................................................................................................................... 3

Motivation ..................................................................................................................................................... 3

Objective ....................................................................................................................................................... 3

System Overview .......................................................................................................................................... 5

Mechanics ..................................................................................................................................................... 6

Revision One ............................................................................................................................................. 6

Revision Two ............................................................................................................................................ 9

Revision Three ........................................................................................................................................ 11

Revision Four .......................................................................................................................................... 13

Sensors ........................................................................................................................................................ 13

Pressure Sensor ....................................................................................................................................... 13

Temperature Sensor ................................................................................................................................ 16

Motor Control ......................................................................................................................................... 18

EMG Sensor ............................................................................................................................................ 19

Power .......................................................................................................................................................... 22

Control ........................................................................................................................................................ 25

Communication ....................................................................................................................................... 25

Microcontroller ....................................................................................................................................... 27

Master Controller Peripheral Integration ................................................................................................ 29

Slave Controller Peripheral Integration .................................................................................................. 33

User Interface .............................................................................................................................................. 36

Feedback ................................................................................................................................................. 36

Budget ......................................................................................................................................................... 46

References ................................................................................................................................................... 47

Appendix ..................................................................................................................................................... 48


2

Team Members

Taylor Furtado

Team Lead, Mechanics

[email protected]

Taylor is a fourth year bioengineering student focusing in rehabilitation engineering. His primary

focus is on designing electro-mechanical systems which assist special needs patients. In this

project his roles will be team lead and mechanical designer of the hand. He has experience with

mechatronics, mechanical design, CAD, embedded C and PCB layout.

Kyle Lawrence

Power

[email protected]

Kyle is a fifth year electrical engineering major focusing on electronics and optics. In this project,

Kyle will be responsible for creating the power system needed to drive all the necessary

components, as well as working on designing the layout of all electronics. He is experienced with

analog as well as digital circuitry, mechatronics, and PCB layout.

Alex Lynchosky

User Interface

[email protected]

Alex is a fourth year computer science major studying microcontrollers and 3D design. In this

project, Alex will be responsible for the user interface of the hand including design and

implementation of the hand’s graphical user interface (GUI). He is experienced with embedded

programming, modeling, and basic mechanics.

Ivan Romero

Controls

[email protected]

Ivan is a fifth year bioengineering/computer engineering focusing on bioelectronics and robotics

respectively. His leading role will lie in designing the control system which will ensure that the

prosthetic properly operates according to user input. He has broad knowledge ranging from

sensors to software development.

Michael Sit

Sensors

[email protected]

Michael Sit is a fifth year computer engineering student focusing on digital hardware. He will

focus on the sensor development aspect of the project and their integration into the prosthetic

hand. He has experience with embedded systems, mechatronics, CAD, and analog circuits.

mailto:[email protected]







3

Abstract

The M.E.C.H team aims to build an affordable and functional prosthetic hand while avoiding the

discomfort of traditional prosthetics. The prosthetic is expected to be capable of grasping common objects

as well as to continuously rotate the grasped object. Through the use of a graphical user interface, the user

will be able to calibrate sensor sensitivity and haptic responses to environmental data. In addition, the

prosthetic will provide feedback to the amputee through the use of haptics and a graphical user interface

to alert the user of equipment and environmental conditions.

Motivation

This project was proposed by Taylor Furtado, a congenital amputee with over a decade of

experience using traditional prosthetics. Traditional prosthetics consist of a hook driven by the leverage of

the opposite limb. This process is very simple for people to learn, however it lacks the functionality of a

real hand and causes significant discomfort with prolonged usage. Furthermore, with maintenance and

production cost, the cost of these prosthetics typically starts at about $30,000. On the other end, modern

myoelectric prosthetics provide user input and feedback using electrodes on the skin of the user’s residual

limb, but at a great cost. An advanced myoelectric prosthetic can cost the user over $100,000.

Our purpose is to incorporate the best of these two systems. Our prosthetic will incorporate the

same myoelectric control and sensor data of modern prosthetics but for a fraction of the cost of either

prosthetic. This prosthetic will be made available online so that any amputee can recreate and even

improve upon our model.

Objective

The purpose of this project is to develop a prosthetic hand system which will provide assistance

to full-hand and partial forearm amputees. The system will consist of a motorized hand, a wrist unit, and a

separate control module connected by a thin tether.

The control module will be positioned on the user’s arm and will be tasked with measuring

ElectroMyoGraphy(EMG) sensors. These sensors will detect the activation of action potentials in the

user’s muscles, based on which target muscles are activated a message will be constructed. The message

will be sent from the command module to the hand, where it will be decoded and actuate either the fingers

or wrist.

The hand module will contain three individually-actuated digits. These digits will be controlled

by the user via messages produced by the control module. The commands will also be able to control the

rotational direction of the wrist. Sensors on the hand will monitor the pressure exerted on the palm, the

temperature of close objects, and the current draw of the motors. The pressure sensors will provide


4

feedback to the user signifying that an object has been grasped. The temperature sensors will ensure that

the user is aware of the held object’s temperature to prevent heat damage. By monitoring the current

draw, it is possible to detect resistance on the fingers, functioning as a limit switch.

The system will provide two forms of feedback to the user: tactile and visual. Tactile feedback

will be provided through the use of haptics located on the control module. The haptics will generate

vibrations directly proportional to the pressure exerted by the hand. An OLED mounted on the control

module will present sensor data. Furthermore, the GUI will display battery life and be capable of altering

the response and sensitivity of the different sensors.

The two modules will share the same power source but will contain their own control logic.

Sensory data, command messages, and system configurations will be sent to each controller through serial

peripheral interface (SPI). The control module will use input from the user to generate position commands

to the hand module (open/close, rotate clockwise/counter-clockwise, etc.) as well as system commands

(turn on, initialize, power down, etc.). The hand module will locally determine best position of the fingers

to accommodate the user’s commands while preventing the hand from being damaged. The sensory data

will then be sent to the command module to be displayed on the OLED.

While the purpose of the project is to make a functioning and comfortable prosthetic, a key

objective is to make the prosthetic widely available. To do so, parts have been chosen that were capable

of performing adequately while cost effective. To maintain this objective, both the hand and control

modules will be fabricated using 3D printing. This approach will not only save production cost, but will

provide a light weight model to less encumber the user.


5

System Overview

Figure 1: System block diagram. Shows high-level electrical connections throughout the M.E.C.H system


6

Figure 2: System Block diagram. Shows top-level mechanical connections and placement of components throughout the

M.E.C.H System.

Mechanics

Revision One

The initial design of the M.E.C.H followed the model of the Open Hand Project [1] which

advertises to be an affordable 3D printed prosthetic for upper limb amputees. Initially the M.E.C.H was

going to be a five-fingered hand similar in size and proportion to a human hand with digits capable of

bending. This design called for a system which could curl the fingers by increasing the tension of a cable

running through the fingers. The curling motion would mimic the familiar finger movements of a human

hand; this design is also outlined in the article: A Multigrasp Hand Prosthesis for Transradial Amputees

by the IEEE [2].

Professor Rosen elucidated the functionality of a prosthetic hand with only three fingers. With

three ridged fingers, a user can pick up 95% of objects. The transition from five fingers to three simplified

the mechanical design of the prosthetic. We sought to create a hand with similar proportions to the


7

average human hand based off of anthropometric data from studies conducted by the U.S Military [3].

Our designs for the hand started with an adaptation of the Open Hand, which would have long rigid

fingers with cables running through the knuckle portion of each finger. The cable driven fingers would

allow us to move the drive train (motors and additional gears) anywhere in the hand, thus allowing the

profile of the palm to be small. Additionally, we designed worm gears as our primary power transmission

system. Worm gears would allow the motors to change the angle of the fingers, but would prevent the

fingers from ‘back-driving’ the motors. By preventing back driving we ensured that forces acting on the

finger would not move the motor and would eliminate the need of running motors to stabilize an object.

With these locking gears we would save power by only using the motors when we wanted to change the

angle of the fingers, rather than having the motors powered to maintain the intended angle.

We selected our gears and motors by performing kinematic calculations to determine our required

torque. Our estimations assumed that the finger would be completely rigid and 3 inches long (76.2mm).

We also estimated that our hand would be capable of holding 5lbs (2.27kg) using the locking of the worm

gears and the friction of the fingers. Our equations are given:

⁄

⁄

Where:

⁄

[the 3 comes from 3 fingers holding the object]

G = gear ratio, η = efficiency, µ = friction constant

So:

⁄

With these equations and given: 2.27kg for Mass, 9.81 for Gravity, 76.2mm for Length, 1.16 for

friction (rubber), a ratio of 1:1 between the Radii of the pulley and joint, a 100:1 ratio for the gearhead, a

20:1 ratio for the worm, and assuming 60% efficiency for the gearhead 100% efficiency for the worms

and 80% efficiency for the motor (typical for most motors and gearheads we researched) we estimated we

would require about 0.6mNm of torque from each motor/finger; we rounded to 1.2mNm to be safe. After

searching we found micro gearhead motors from Pololu which provide a wide range of speeds and

torques by changing stall currents and gear ratios. We settled on high-power motors with a 100:1 ratio


8

which would provide: per motor/finger which is far more than we required.

Our first revision of the hand attempted to use the pulley system from above, but did not retain

the human hand proportions (see figure 1). Rev1 used four concentric disks for structure with cutouts

designed within to allow for drive trains, motors, controllers, sensors, and other hardware. The disks were

held together by M6 screws which ran down the length of the hand as well as tabs which kept the disks

oriented and helped with assembly. Additionally, there were a second set of screws on the palm which

allowed the front of the palm to be removed without disassembling the entire hand. This allowed us to

maintain the PCB containing the environmental sensors embedded in the palm without disassembly. The

profile of the hand had three knuckles/fingers in an equilateral configuration (i.e. the knuckles were

equally spaced around the circular profile). This allowed the design to be simplified (each finger could be

designed once then duplicated).

Figure 3: Revision 1 of the M.E.C.H. (Top) Exploded side view of hand, (Bottom Left) Transparent and non-transparent

side and isometric views of hand, (Bottom Right) side, front and isometric views of drive train

The drive trains of Rev1 consisted of two perpendicular axles, one containing the motor and

worm gear, the other containing the pulley and worm wheel (see figure 1). Both axles were held in place

by 3mm and 5mm ball bearings. The motor of the drive train was held in a square compartment in


9

motor_cap_2 with two metallic washers to prevent the motor from spinning. We found this to be an

effective method of holding the motors in place, while insuring the plastic will not bend over time. Lastly,

the drive train was spaced and positioned in such a way to ensure the pulley was directly behind the

knuckle in order to prevent bending of the cables.

After designing and fabricating the first revision of the hand, we quickly found that the pulley

system and gearboxes took a large amount of horizontal space (outwards, parallel with the user’s arm)

making the hand unreasonably long (nearly 100mm). To ensure the equilateral configuration of the

fingers whilst allowing room to grasp objects, the diameter of the palm was unreasonably large (105mm).

Additionally, the pulley system was mechanically complicated and was unfeasible based on our time

constraint and mechanical engineering experience. For example, we found that to maintain tension

without stretching the cabling, the cable would have to remain parallel to itself as it turned. This required

us to create our own custom pulley as depicted in figure 4. Furthermore, fixing the ends of the cable to the

knuckle without warping plastic presented a large degree of difficulty. Preserving space while

maintaining a rigid fixing point proved to be outside our scope of knowledge, thus we began to

conceptualize a new form and mechanism.

Figure 4 Cross section of pulley in three major positions: (from left to right) finger open, finger mid-position, finger

closed

Revision Two

As we found that Rev1 was less feasible, we archived revision 1 and moved to revision 2 (see

figure 5). Rev2 was also a layered hand, but used a direct drive system rather than a pulley. This new

system used a worm gearbox directly connected (on the same axle) to the knuckle. Removing the pulley

and attaching the worm gears directly to the knuckle improved the efficiency and simplicity of the design

and changed the kinematic equations to:

⁄

Where:

⁄

[the 3 comes from 3 fingers holding the object]

G = gear ratio, η = efficiency, µ = friction


10

So:

⁄

Because of the assumed 1:1 ratio between the pulley and the knuckle, the required torque is the same

mathematically, but without the resistance of the pulleys and cables the efficiency is increased.

Furthermore, we sought to increase the efficiency of the design by adding ball bearings on the knuckles

and gearboxes. This is different from Rev1 where we had a plastic-on-plastic interaction for the knuckles

and their socket, which added a considerable amount of friction to the drive system. The direct drive

trains were more compact thus allowing us to reduce the profile of the hand.


side and isometric views of hand, (Bottom Right) side, front and isometric views of drive train. This revision was fitted

with fingers.

Without the pulley system, the entire drive train was significantly shorter, thus reducing the

overall length of the hand by 20mm, and allowing us to remove one layer. By reducing the amount of

layers the hand was comprised of, the hand was simpler to manufacture. We also determined that the

equilateral configuration for the fingers from Rev1 made grasping most objects difficult due to the limited


11

distance between the joints of the fingers. For this reason we changed the finger configuration to be

isosceles, meaning that two fingers are equidistant from the other finger but not each other. This

configuration allowed the hand to grasp larger objects, and made the hand’s shape closer to that of an

actual human hand (heart-shaped rather than round).

In addition to the changes in the drive trains, more consideration was put into the design of the

printed circuit boards for the environmental sensors and the control boards; Rev2 was designed about the

same time as these PCBs. In Rev1, we assumed that each motor driver would have its own PCB, and

when Rev1 was designed there was no intention of having multiple microcontrollers. With Rev2, we

wanted to have two PCBs for the entire hand, one for the environmental sensors embedded in the palm,

and one board which would contain the three or four motor drivers and the hand controller. This decision

required a large open space in the back of the hand for the PCB.

Revision Three

The last revision of that hand came about because of a last minute change in the size of the worm

gears. Rev3 is similar to Rev2 in shape and size, though because of the larger size of the gearboxes, we

were required to redesign the orientation of the knuckles, the space allocated for the gearboxes, the

placement of the motors and screws, and the shape of the hand’s profile (see figure 6). Also, after further

design of the hand PCB, we found that additional space was required for the controller PCB and

environmental PCB. For this reason, the rear of the hand was redesigned to provide greater floor space to

mount PCB and square sides to make mounting and positioning of the PCB easier. Lastly, the knuckles

were redesigned to provide more space between the edge of the knuckles and the bearings, reducing

friction and giving more space between the palm structure and the rotating finger.


12


side and isometric views of hand, (Bottom Right) side, front and isometric views of drive train. This revision was fitted

with fingers.

The redesign of the gearboxes and fingers from Rev2 allowed the hand to reliably grasp objects

of moderate weight (about 2 lbs.). The current fingers on the hand allow for grasping round and square

objects, but fails at grasping small or thin objects. The knuckles will be designed such that fingers could

be easily swapped. This design choice allowed for customized fingers adept at grasping specialized

objects, as well as fingers capable of functioning for everyday use.

The M.E.C.H requirements also stipulate a wrist capable of rotating in a continuous circle. While

this was not a requirement for this quarter, the design and placement of the wrist was considered in

designing Rev2 and Rev3. During the design of Rev2, we designed a wrist attachment to the rear of the

hand which included a thrust bearing and slip ring which will connect the rotating hand to a fixed base

attached to the user. The wrist is currently not developed and will not be included until Rev4.


13

Revision Four

While Rev3 is the current working model of the hand, it has raised concerns which we will

resolve in the next revision. Rev4 – yet to be designed – will be more capable of accommodating a wrist

and base to the back of the hand. Currently, Rev3 has an attachment for a small thrust bearing, but

estimates show that we will require a larger, more stable bearing to hold the hand and rotate

simultaneously. Moreover, Rev3 does not have the capabilities of housing the additional gearbox and

motor for facilitating the rotation of the wrist; these features will be included in Rev4.

We also determined that the flat profile of Rev3 is not ideal for grasping objects. We observed the

morphology of our hands as we grab objects and have discovered that rarely is the palm of the hand flat.

For this reason we are attempting to design a curved profile for the face of Rev4 which will be similar to

the curvature of the human hand.

Rev3 also lacks an aesthetic appeal, which our group and outside sources recommend

considering. Rev4 will attempt to resemble not just the size and proportions of a human hand, but also

include textures and features to give the hand the look and feel of a natural hand.

Sensors

An objective of the project is to provide the prosthetic user intuitive control and sensory

feedback. More advanced prosthetic limb projects like DARPA’s Revolutionizing Prosthetics program

require natural sensory feedback to the user with their prosthetics. That is, “develop sensor and actuation

mechanisms that can allow a user to feel what the prosthetic hand is feeling, be it force, texture, or

temperature.” [4].

Pressure Sensor

Touch sensing is the detection of an applied contact force at a specific point. At the very

minimum, touch sensing can be restricted to binary information, namely touch and no touch. Tactile

sensing is the detection and measurement of a distribution of forces at a specific sensory area. We can

consider tactile sensing to be an organized group of sensors. Currently there are no tactile sensors that will

suit most applications. We must choose a touch sensor that will be able to function according to our

application requirements.

Our sensor should have a sensory area small enough to fit onto the face of the palm. It must be

small in volume so it does not take space away from other electronic and mechanical devices located

inside the palm. A sensitivity within the range of 0.25 to 20N is estimated to be able to detect touching of

everyday objects. Additionally, a consideration for mechanical overload is required to account for the

stresses of everyday use. Finally, the sensor reading must be stable, repeatable, and predictable.

Types of touch sensors

Mechanical sensors: These sensors function as switches and are classic examples of a binary


14

touch sensor. The force required to elicit a response is determined by the applied force. The applied force

must pass the threshold for the sensor to activate. Mechanical sensors are easy to use and are robust in

normal situations.

Force Sensitive Resistor: FSRs exhibit a change in resistance with a force applied to its surface.

Typical response behavior of a FSR is non-linear, but can be extrapolated. It is relatively simple to

interface with a microcontroller and can operate adequately in moderately hostile environments.

Capacitive based sensors: A capacitive sensor relies on an applied force changing either, the

distance between plates, surface area, or dielectric medium. A popular method of measuring capacitance

is based on the use of a precision current source. Problems with capacitive sensors can be caused by stray

capacitance from the close proximity of metal structures.

Magnetic based sensors: These sensors rely on the movement of a small magnet through a

magnetic field and causing the flux density to change. It has high sensitivity, low mechanical hysteresis,

linear response, and is physically robust. Measurement of flux can be made by the Hall Effect.

Optical Sensors: By moving an obstruction into a light path, the intensity of light can be

modulated. Another technique to modulating the intensity of light is stressing a photo elastic medium.

These sensors are safe, low weight and volume, but require optical processing.

Strain gauges: A strain gauge will detect the change in length of the material as it is subjected to

external forces. A typical type of strain gauge used for prosthetics is the load cell. It converts mechanical

force into an electrical signal making it easy to utilize in an electronic system.

Force Sensitive Resistors

Force sensitive resistors are the best choice for our needs. It is easy to interface with a

microcontroller through a resistor divider network. It is less than 2mm thickness, the thinnest of our

researched pressure sensors. The sensitivity range of the FSR spans 0.01 to 100N, more than what is

required for a touch sensor. The sensor’s force sensitivity is optimized for use in human touch control of

electronic devices. Although it has a non-linear response, it is predictable and further information

processing can be used to achieve accurate measurement. It is mechanically robust enough to handle the

grasping forces of the prosthetic hand.


15

Figure 7: Force Sensitive Resistor used in M.E.C.H

Three force sensitive resistors, like the one shown above, will be attached to the face of the palm.

It will be placed in a triangular pattern and laminated by thin, uniform adhesives. This sensor array will be

used as feedback for the prosthetic user. Future designs will include pressure plates on top of the FSRs for

wider sensory area.

Force-to-voltage conversion

The force sensitive resistor should be sensitive enough to detect rigid objects pressing against the

surface of the palm without assistance from the fingers.

Table 1: Voltage vs applied force of force sensitive resistor circuit in various resistor values. By Interlink Technologies,

FSR400 datasheet

The force sensitive device is tied to a measuring resistor in a voltage divider configuration

buffered by a unity-gain op-amp. A capacitor is put across the measuring resistor to stabilize the signal

providing a smoother response.


16

Figure 8: Force Sensitive Resistor circuit

The DC output of the converter is described by the equation:

A 47kΩ measuring resistor allows for reliable granular sensing on forces under 200g (see table 1)

but tapers off above that value. Since our goal is to sense the moment of contact, higher contact forces are

already reflected.

Pin 1 of the Op-amp will drive the microcontroller’s A/D converter and will be processed in

software. The microcontroller can use this information to provide haptic feedback to the user through

another device.

Temperature Sensor

Our temperature sensor must be able to measure temperatures at distances of under six inches. It

will be used to protect the hand, alert the user to potentially damaging conditions, and provide a basic

replacement to the sensory glands on a human hand. These requirements narrow down the options of

temperature sensor technologies and rule out contact measurement as plausible implementation for

distance measurement.

Our biggest concern when selecting a temperature sensor was to ensure it fits within the

environment of the palm. It must be small enough to allow for space of other crucial components and also

be robust enough to be unaffected by the heat generated by the motors.

Infrared Thermometers

Every form of matter with a temperature above absolute zero emits infrared radiation according to

its temperature. The spectrum of infrared radiation ranges from 0.7 to 1000 um wavelength. The infrared

spectrum is not visible to the naked eye but is visible to infrared sensors. [5]


17

Figure 9: Infrared Thermometer used in M.E.C.H

The ZTP-101T shown above is an IR thermopile sensor in a small package of 3x3 mm2. Included

within the sensor is a thermistor used for ambient temperature compensation to account for the heat

generated by other components, namely the three DC electric motors. It is sensitive, has a fast response

time, and costs $5. This particular temperature sensor responds to 6 to 16 um infrared wavelengths. This

region is where most objects behave as black bodies. Non-black body means the object has added ‘color’

components which cause distortions that reduce accuracy.

Viewed from a device standpoint, this sensor operates as a voltage source with outputs from -5 to

5 mV at 100C and can go below 0 mV below 25C. Two of the pins seen in the figure above are the

internal thermistor. In simple cases, one can use the following equation for reading the thermopile sensor:

[

]

s = Sensitivity

e = Emissivity

k = Instrumentation Factor

The sensitivity factor is specific to the device, but the emissivity and instrumentation factor is

determined by the object being measured. For most objects, we can assume e to be 0.85 to 0.95.

Reflective metals have lower emission factors, and we discovered during testing that surface temperatures

of reflective metals cannot be reliably determined. The instrumentation factor k depends on the object’s

position in the sensor’s field of view. The objects position in relation to the sensor cannot be determined

without additional sensors, so we will assume k = 1 (zero radian).

The sensor module will be embedded inside the middle of the palm, with a circular opening for

the thermopile to “see”. We envision it to be used in conjunction with haptic feedback. As the user’s

prosthetic hand approaches, for example, a very hot object, the user will be alerted via vibrations on his

arm.

Ambient Temperature Compensation

From the equation above, the output of the thermopile sensor is a function of the temperature

difference of the object and the sensor. Therefore, to obtain an accurate reading of the object, it is


18

necessary to account the temperature of the sensor. Issues can arise from the heat generated by the three

DC electric motors located next to the thermopile. A voltage is generated from tying the thermistor to a

voltage divider configuration and measuring a resistor. This voltage is added to the voltage of the

thermopile in the analog circuit.

Sensor Module

Our microcontroller’s A/D only reads up to 3.3 V. We employed multi-stage operational

amplifiers with a total gain of 368V/V, a low-pass filter, and buffer. We discovered our op-amps have

poor performance when the op amps rails are tied to positive and negative volts. We discovered our

sensor outputs a negative voltage when measuring extremely cold objects, thus we employed a rail-

splitter circuit to offset the ground reference voltage to 1.65 V.

Motor Control

Figure 10: Micro Gearhead Motor used in M.E.C.H

The motor shown above draws 1.5A when stalled. The most important consideration in selecting

an h-bridge is an IC that can sink 1.5A. The second crucial element in selecting a motor controller is

current sensing. The software needs to determine when the fingers have fully grasped onto an object. The

method for determining the force acted on the object is by means of current sensing. As the motors

encounter resistance to its actuation, it will draw more current until its maximum rated value is reached.

When the motors have begun to stall they can no longer apply additional force. By measuring the current

draw of each motor, we can determine how much resistance the fingers are facing as it grasps on the

object.


19

Figure 11: 16-pin SOIC package of A4973 motor driver

A4973 Full-Bridge PWM Motor Driver

This motor driver is designed for bi-directional PWM current control of electric motors operating

at a maximum current of 1.5 A. It features, internal kickback protection, current sensing, current limiting,

thermal shutdown protection, and costs $6 per chip.

Current Sensing

As a method of determining the grasping pressure, the current draw of the brushed DC electric

motor is measured using a shunt resistor attached to the sense pin. A shunt resistor of 0.39 ohms and

0.5W power rating is connected to the sense pin and ground. The voltage drop across the shunt is

measured to determine current draw. Due to the very low resistances of the shunt, other resistances

normally not considered such as PCB trace resistance can affect current readings; hence it is important to

have a short PCB trace return path to the ground pin.

Current limit

The A4973 is a small 16-pin SOIC motor driver used for a single motor. It includes a selectable

current limiting circuit to control the maximum current draw of the motors. This can be employed to

prevent current overdraw to protect the motors from generating too much heat and provide an upper limit

on maximum torque. This maximum current is determined by:

Vref: voltage reference

Rs: Sense Resistance

Since the current sense resistor is selected for current sensing, the current limit is controlled by varying

the voltage reference pin.

EMG Sensor

Electromyography, or EMG, is a method of interpreting the electrical signals produced in skeletal

muscles during contraction through the diffusion of Na, K, and Cl ions. To detect the neuromuscular

signal, two electrodes are placed on a given muscle group. The electrodes are placed so that one electrode

sits farther down the muscle than the other, picking up two signals with amplitudes in the millivolt range.


20

Figure 12: EMG Sensor placement on various muscle groups. It is important to place the sensor nodes on the same muscle

groups, separated by some distance. Image by: Amos Zweig, “Controlling a crane arm with EMG sensor, Bachelor-Thesis”

2011

These signals are generally differentially amplified by an instrumentation amplifier with a low

offset voltage and high gain-bandwidth product in order to preserve the information in the signal.


21

Figure 13: EMG signal output for both sensor nodes (top two graphs) and their differential output (bottom graph). This

signal was obtained by measuring the bicep muscles, where the user was asked to raise their arm after 2.1 seconds. It is

important to notice the high dV/dt in the differential signal, which is what we use to create a smooth, low-frequency

signal. Image by: Plessy Semiconductors, Application Note #291391

In more advanced applications of EMG sensing, the differential signal is translated from the time

domain to the frequency domain using FFT, where the frequency data delivers the information about the

muscles activity. For our application of EMG sensing, we went with a simpler approach, which we


22

discovered while experimenting with an EMG breakout board from Sparkfun Electronics.

Our method of utilizing the differential signal produced via EMG would be to measure the

change in signal with respect to time, and then translate that voltage into a low frequency signal from 0-

3.3[V] for the microcontroller to interpret. The amplified differential signal first passes through a

precision absolute value circuit, where the signal is rectified using a series of diodes and op amps. From

here, the signal passes through an op-amp integrator circuit, which removes much of the high-frequency

components of the signal. With the majority of the signal amplitude degraded through the filtering

process, a gain stage is necessary to amplify the conditioned signal to a usable level. In order to properly

interface with our microcontroller, we needed to add one last stage to the circuit, to shift the logic level of

the analog signal from 0-5[V] to 0-3.3[V].

Figure 14: EMG schematic. This design employs a circuit similar to the Muscle Sensor v3 Kit from Sparkfun Electronics.

Input signals are differentially amplified, rectified, and smoothed to obtain a low-frequency output signal.

Our reason for choosing this method of interpreting the EMG sensor was due to how easy

interpreting the output signal would be. Performing FFT on the signal for analysis would consume a great

amount of overhead, and considering that our design calls for three separate EMG signals, we decided not

to use this method. The circuit needed to implement our method of EMG sensing is fairly simple, and the

end resultant signal is an easy to interpret, low frequency that can be utilized through some form of digital

hysteresis programmed into the microcontroller.

Power

Due to the portable nature and functionality of our project design, we needed to design a power

distribution system that would be capable of providing the various voltage rails necessary for the circuits

in our design. In order to determine how much power would need to be provided for each voltage rail, we

created a power budget, which shows the operating voltage for specific components/circuits, as well as

their current draw at worst-case conditions. Based off of the design constraints derived in the power

budget, we were able to choose components capable of supplying the power needed.


23

Table 2: Power budget calculations for entire prosthetic hand project. This power budget takes into consideration the

worst-case current draw of all of the components used to provide design constraints for the power supply.

When considering which battery to use in our design, we took into account the various properties

of different types of batteries. Because of our usage of four brushed DC motors to actuate the fingers, our

battery would need to have a high enough charge density and discharge rate to supply the current needed

by the motors. For our design, our primary consideration in terms of the battery was how safe it was to

charge/discharge, as well as size and weight. High charge density batteries, such as lithium-polymer

batteries, have the potential to cause harm when used improperly, and have been known to have

undesirable characteristics when charging. After researching safer high charge density batteries, we chose

to use a two-cell Li-Fe-PO4 hobby battery with a nominal voltage of 6.6 [V]. We chose this battery

because it would be able to provide a range of +6 to +7.2 [V] without damaging the battery, it is relatively

lightweight in comparison to other types of batteries, and most importantly, it is one of the safest types of

high charge density lightweight batteries.

With our battery chosen, we knew the minimum input voltage for our power distribution system,

which provided some insight into which type of voltage regulation we would employ. Referencing our

power budget, we found that the majority of our current draw on a regulated voltage line was on our +3.3

[V] rail, whereas only a few milliamperes would need to be sourced by the +/- 5 [V] rails.

In order to minimize thermal losses and increase overall efficiency, we chose to use a switching

regulator rather than a linear regulator, specifically a buck-regulator, which would step down the input

voltage to a +3.3 [V] output. When choosing a switching regulator, we needed to find one which could

provide over an Ampere of current output, while also having an under voltage lockout feature to prevent

potentially damaging the battery. Based off these constraints, we ended up using the Linear Technology

LT1376 step-down switching regulator.

For the +5 [V] rail, we chose to use a standard fixed output linear regulator. The low current draw

and small voltage drop means that losses due to heat would be minimized. Our choice of the Texas

Instruments LM1086 linear regulator provided us with a fixed regulator that could provide the needed

current with a minimal amount of components. In order to provide the -5 [V] rail needed by the

instrumentation amplifiers in the EMG circuits, we needed to find a component which could take an input

voltage and invert it. One means of inverting voltages requires the usage of an inductor and switching

elements, which can take up considerable amount of space on a PCB. Rather than use a switched

inductive inverter, we ended up using a switched-capacitor inverter, specifically the Linear Technology

LTC1046, creating the needed -5 [V] rail with only two other components.

Component Current (mA) Power (mW) Quantity Component Current (mA) Power (mW) Quantity Component Current (mA) Power (mW) Quantity

Haptics Motors 70 231 2 EMG Circuit (+5V) 10 50 3 Finger Motors 1000 6000 3

H-Bridge 3.5 11.55 4 EMG Circuit (-5V) 10 50 3 Wrist Motor 1000 6000 1

µC 200 660 2

OLED 310 1023 1

FSR Circuit 0.1 0.5 3

Temp Sensor 0.1 0.5 1

Total 864.4 2853.2 Total (+ 5V) 30 150 Total 4000 24000

Total (- 5V) 30 150

(+ 3.3V Rail) (± 5V Rail) (+ 6.6V Rail)


24

Our original layout of the regulators had the +6.6 [V] from the battery regulated to +5 [V], then

from there +3.3 [V] and -5 [V]. Using this layout proved to be challenging, in that the linear regulator

would have a large change in its ambient temperature when having to source all of the current needed by

all of the power circuits. To reduce the amount of current passed through the linear regulator, we decided

to hook up the switching regulator in parallel with the linear regulator. This meant that the majority of the

current would be sourced by the switching regulator, which is much more efficient when it comes to heat

losses. With this configuration, we were able to minimize the current sourced by linear regulator, and

eliminate large fluctuations in the temperature of the circuit.

Figure 15: Schematic for power supply topology used.

Given the layout of the power circuit, as well as the expected worst case scenario current draw

for each voltage rail, we calculated the expected junction-to-ambient temperature change for the

switching regulator as well as the linear regulator. We expected the switching regulator to have the

highest fluctuation in temperature, due to the fact that this component had the largest voltage drop via

regulation, and also because the majority of the current for all of the components. When calculating the

thermal fluctuation for the linear regulator, we were presented with a series of different thermal

coefficient values for the different packages that the regulator was offered as. Overall, we expect


25

changes in the ambient temperature of the power circuit to be at a level where they are “touch safe”.

Table 3: Thermal calculations for each regulator component used in the power supply. This was done to ensure that the

power supply would not generate too much heat, as this would ultimately end up being attached to the user.

Control

Communication

The use of motors raised concerns over possible issues with our sensor readings. In order to

maintain the cost effectiveness of our design, we chose to use brushed DC motors. We chose to use toy

motors, however these were not designed for the use of accurate applications and thus held a likelihood of

adversely affecting our sensors readings. Electromagnetic fields created by the motors could distort the

readings from our sensors. To separate our data we decided to set up a pair of microcontrollers, one set at

the hand of the prosthetic and another on a command module set on the upper arm. Furthermore, we

acknowledged that having two controllers would simplify the process of debugging. Since our controllers

would be handling a variety of events that could alter the desired outputs by dividing the work we

believed it would be easier to assemble.

Prior to choosing our microcontroller, we discussed various means of communicating between

two devices. We considered using controller area network (CAN), serial peripheral interfaces (SPI), inter-

integrated circuit (I2C), or universal access receiver/transmitter (UART). We began inclined to use CAN

communications because a member had previous experience with the communications. However upon

research and comparisons we ultimately decided to use SPI.

Package Type: LM1086-5 (+5V) ΔT LT1376 (+3.3V) ΔT

SOIC ------------------- 36.17°C

SOT-223 14.96°C -------------------

TO-220 8.69°C -------------------

TO-263 10.12°C -------------------

PFM 6.05°C -------------------

WSON 4.4°C -------------------


26

Figure 16: Comparison of communication systems

Despite UART being the most widely used form of microcontroller communication, its

susceptibility to noise made it an unlikely choice for our design. Fluctuations caused by the running

motors could easily distort the output line and mistake it as a message. Incorporating check sum and

parity bit checking would help to ensure that the proper data was being sent out. Despite this, it still

limited the ability to communicate with a variety of peripherals.

While UARTs were limited to one to one communications, the CAN bus system would allow us

to communicate to a much larger variety of peripherals. Furthermore, since the system is designed to

incorporate a large set of elements, the system reads from a differential signal to prevent distortion from

noise. In a CAN system, differential impedance is used to implement noise immunity. This ensures that

the messages can send accordingly and correctly, but causes a higher current draw than other systems

when off. While these characteristics made the CAN system ideal for our project, the overhead of setting

up the bus system was substantial enough to require reconsideration. The CAN system requires a host

processor along with an external transceiver to function properly. Based on experiences from other users

we chose to forgo this form of communication.

The allure of multi peripheral communication was met by I2C communications while producing

less overhead. I2C can communicate with only two wires for clock, receive, and transmit. While I

2C

could communicate with multiple devices, setting up the system was believed to be incredibly difficult. In

order to get messages across, we would spend a great amount of time just preparing without being able to

see if our dual systems were functioning.

Our findings led us to believe that SPI would be the easiest system to set up while still providing

the functionality we sought after. SPI would require four lines to allow for master out slave in, master in

slave out, slave select, and clock. If a device was not selected for communication and it was not selected,

its output would not be received by the master. This functionality prevents unwarranted messages from

interrupting the master controller, without having to worry about resolving collisions or handling bus


27

addressing. Having selected our form of communication we knew that we wanted to have a

microcontroller that could interface with SPI.

Figure 17: Master Slave wiring connections.

Microcontroller

We were aware at this point that the microcontroller needed to have SPI communications readily

available and could thus interface with other peripherals. Next we needed to know how many general

purpose input output pins we would need in order to properly accommodate all of our components.

Figure 18: Slave controller pin requirements.

The hand controller would be largely in charge of performing operations to control the motors on

the hand. The hand would be consistently measuring environmental data to ensure that it remained within

appropriate working conditions; this task would be accomplished by measuring temperature, pressure, and

current draw. The hand will be programmed to send SPI messages to the master module; these would be


28

decoded for the end user to see. Upon receiving messages from the master it would be able to open and

close accordingly. An ideal characteristic of the hand is its ability to function without constant

interference from the hand. Ideally this configuration would allow the user to configure the sensitivity of

the peripherals through GUI, without having to understand the software operating the motor drivers.

Figure 19: Master controller pin requirements.

The master controller would require a minimum of 13 pins. Initially, the controller was expected

to incorporate digital potentiometers that would be modified through SPI. However, closer analysis of

their characteristics revealed an inability to support our EMG sensors, thus they were removed from the

project. The EMGs would be read through the commander and upon activation would write a message to

the hand controller to operate the motors. Upon receiving sensor values, the master will decode them and

display them onto a GUI interface. Haptic motors will be activated if the sensor readings correspond to

values that could potentially harm the prosthetic.

For the purpose of debugging, we allocated pins for UART. This would allow us to disperse print

statements throughout our code. At any given time, finding error in our logic would be simplified by

reading through terminals. We had originally planned on having a separate SPI channel for the hand

module and for the GUI, but to conserve space we ultimately decided to consolidate the two.

We narrowed our choices to three different devices that we felt comfortable working with and

that could satisfy the minimum specifications of our devices. Furthermore, we wanted to choose a device

that we were familiar with and would provide a friendly programing environment. The majority of us had

taken a course on mechatronics and was familiar with the PICMX320F128H, a microcontroller embedded

in the Uno32 development board. Regardless, we wanted to look around and see what other controllers

we had available to us.


29

Figure 20: Microcontroller parameter specifications.

We had a preference for Microchip technologies because most of us were already familiar with

the MPLAB X IDE. However, we initially turned towards TI’s MSP430 series because we were drawn by

its low power consumption. The chip we had found hit our specifications exactly, but upon further

research we realized that its environment had a code limit. Unless we were willing to pay for the software

there would be software size limit that would prevent us from using it any further. We want our project to

be open source and have it be altered by experienced users to better improve what we construct. Using

code composer would severely limit our ability to do so, thus we opted away from the TI family.

The pic24 was known for its extreme low power conditions which rivaled the operating

conditions of the MSP430. While the chip fit the characteristics that we desired, it maintained a fair set of

distinctions from the PIC32 family that would have led prototyping with a development board useless.

Thus, we settled on the Pic32MX series. We were initially inclined to use the 150 series as they

were easier to solder and still contained all of the utilities required for the project to function properly.

However, this chip held some differences that would later make testing difficult. This particular chip

required pin peripheral select in order to properly set pins. This would deter us from using the libraries

that had been written for the Uno32. Furthermore, its interrupts were configured to function as persistent

interrupts. These interrupts would remain active until the event that caused them to activate was rectified.

Finally, since we had the most practice with the chip, we decided to use the PIC32MX320F128H.

It was the same size as the other Microchip controllers and yet still had better operating conditions.

Despite having a larger current draw, relative to the draw of the motors it would make relatively little

difference.

Master Controller Peripheral Integration

Integration of all of the peripherals required the use of a state machine to keep track of event

information. The state machine would interpret sensory data received through SPI, EMG activity, and


30

push button configurations. To properly catalog the events that passed through the state machine, a

circular queue was constructed to store information. A circular queue allows new information to be

stored, while having only a finite set of data allocated. By increasing the index location and using the

modulus of the total data size, it is possible to store new information over old data. The state machine

grabs events from the queue and then performs an operation based on its current state.

Figure 21: Framework for state machine flow control.

After the framework has checked for any events, it passes the recorded event into the state

machine to proceed to the next state. The state machine was designed such that the user would feel no

encumbrance as they attempted to control the hand. Seamless integration was essential when designed.

We wanted the user to control the hand, yet keep the GUI updating new information.


31

Figure 22: Master state machine.

The controller resides primarily within the Idle state and waits for an event to occur. Since the

master controller must wait for the slave controller to send it sensor values, a timer is set so that upon

expiration requests values from the slave controllers. If the slave does not send out values within the

allocated time, the controller returns to the idle condition.

The most important state of the state is the Controlling state. Within Controlling the user’s EMG

command is sent to the slave controller. Within each state, if the user activates the EMG sensors, the state

machine will approach the Controlling state. Within this state, the master will send out command

messages that will be decoded by the slave controller. Similar to the Requesting state, if a timeout occurs

due to a lack of confirmation, the state returns back to idle.

Finally, if any button is pressed the controller will be in an Interfacing state where it will be

updating the GUI. Upon pressing buttons the user can control the sensitivity of the EMG sensors as well

as the response from the haptic feedback. Similarly, upon timeout the controller returns to Idle otherwise,

if a sensor is triggered it returns to the Controlling state.


32

Figure 23: Event checking flow chart.


33

Each peripheral is checked in a very similar fashion, each of them updates the current state and

condition. If the measured values manage to exceed the bounds of hysteresis, they will be updated and

will register as having activated an event. The hysteresis bounds are set to prevent any bounce or

undesired signal from activating an event and switching states undesired.

Slave Controller Peripheral Integration

Figure 24: SPI Messages used on M.E.C.H. Command messages go from master to slave and are used to change the

position of the fingers and wrist. Status messages go from slave to master and are used to report the values of the

environmental sensors and current sensors.

The slave controller works similarly to the master, albeit it is completely isolated from the user.

The slave is an autonomous controller which uses command messages from the master and sensor

measurements to position the fingers of the hand to appropriate angles. The slave uses a finite state

machine controller (see figure 25). This controller primarily waits for input from the master but also uses

internal timers to check and process sensor data and set motor positions.

Figure 25: Flowchart diagram of the slave FSM

Command Message

Bit ID msgTyp_1 msgTyp_0 Enable CW CCW ID_1 ID_0 Direction ID_1 ID_0 Direction ID_1 ID_0 Direction

Bit Number 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Status Message

Bit ID msgTyp_1 msgTyp_0 ID_3 ID_2 ID_1 ID_0 Val_9 Val_8 Val_7 Val_6 Val_5 Val_4 Val_3 Val_2 Val_1 Val_0

Bit Number 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Message Type Sensor ID Analog Value

Message Type Wrist Middle Finger Left Finger Right Finger


34

After initialization, the slave FSM will wait in its Idle state until either an SPI message is sent

from the master or one of its two timers have triggered. The SPI messages are handled immediately when

they are received due to interrupts. When the message is received, it is decoded to update global

structures within the code which retain the current position and commanded position, the current draw

and the current duty cycle of each motor; each motor of the hand (three fingers and wrist) has its own

individual structure. After decoding the receive buffer of the SPI bus is cleared and prepared to receive a

new message.

The other events that trigger a response of the slave are internal timer expirations. There are two

timers used in the slave: an update timer and a status timer. An update timer expiration event triggers the

state machine to transition into the Updating state in which one of two processes may happen. If the

ChangeFlag (a static flag variable) is set to the value: DON’T_CHANGE, the slave will execute the

function UpdateSensors() which updates the status of the environmental and current sensors. After about

30 iterations of UpdateSensors(), the ChangeFlag will change its value to CHANGE; the number of

iterations can be changed by the user. At this point the slave will set the position and speed of the motors

using the function SetMotors(); seen in figures 26, 27 and 28. The update timer is set for a short

duration(around 1ms) to ensure fast responses to external events.

Figure 26: SetMotors() Flowchart diagram


35

Figure 27: ToggleFingerPos() Flowchart diagram Figure 28: MaintainGrip() Flowchart diagram

SetMotors() is the primary function to manipulate the physical hand configuration. The function

has two routines: toggle and maintain, and the function is called individually on each motor. Toggle

occurs when the commanded position and the current position of each motor is not the same (OPEN or

CLOSE). If this is the case, ToggleFingerPos() will move the motor in question toward the commanded

position until the current limit is set beyond some user defined threshold; signifies the finger has met

some resistance and should stop. When the final position is reached, current position is set equal to the

commanded position. MaintainGrip is a routine which is called when the commanded position and the

current position are both set to CLOSE. This routine pulses the fingers on a set interval toward the

CLOSE position to ensure the fingers are fully closed. This is a check against objects which change shape

or move after the hand initially closes on them.

The other event which will trigger a response from the slave is a STATUS_TIMER timeout. With

a status event the state machine transitions to the Sending state. Currently the sending state prints the

status of every sensor, motor and value of the finger structure back to the user via the program terminal.

This is an effective mode of debugging the hand during operation. Later, the sending state will trigger the

slave to send a series of status messages to the master reporting the value of each sensor and motor. The

transition to this state will also later be triggered by a request message sent by the master signaling that

the master is ready to receive status messages.

After one iteration of either the Sending state or the Updating state, the slave FSM will return to

the Idle state to await another timeout of message event.


36

User Interface

When we first decided to design the prosthetic hand, a GUI was not believed to be necessary.

After learning how the different sensors, motors, and other peripherals would have to be tuned and

customized to each individual person, a GUI became an essential part to how our hand would work. It is

now a central part of our design in how we convey information to the user, and can be easily adapted to

numerous situations.

The GUI acts as an interface between the user and our peripherals. The user is able to navigate

through each screen and set the desired thresholds for each sensor and motor. By enabling each peripheral

to be uniquely modified, our prosthetic hand can be used by a much larger base of people, and it can adapt

to different situations. The versatility of the GUI implementation can be noted in the modification of the

pressure thresholds. If the user feels that the EMG sensors do not respond adequately to their commands,

they may reduce or increase the threshold for the activation of controls.

The GUI will be displayed on a 3.2” diagonal OLED. This unit has 256x64 pixels and has an

integrated on board PCB that converts the signals from the microcontroller to be used accordingly by the

OLED. The text is mono colored and to conserve battery power will remain on a black background. The

GUI will be mounted on the users upper arm where they can see the sensor readings and modify

sensitivity.

The user will communicate with the GUI using three separate buttons placed on the command

module. These push buttons will be used to navigate across different screens and will have different

functionalities with each screen. The buttons will wither modify a value on the screen or will change to a

different screen.

Feedback

The GUI will have a haptic feedback system to let the user know the status of the peripherals The

OLED will display the battery life, the condition of the temperature sensor, the pressure sensors, and the

EMG sensors. This simplistic layout will be the base for every screen involved in the GUI. We chose this

simple layout because it provides a large amount of information in the small area provided. By separating

the screen into three main parts (buttons, information display, and peripheral status), it creates a sense of

continuity that will keep the numerous screens from becoming too confusing to understand. We really

wanted the GUI to be as functional as possible without being too overbearing to learn, as learning to

control the prosthetic hand itself can be a challenging task.


37

Figure 29: Display layout for GUI interface. *Note, these images are simulated through NetBeans, not actual OLED

display.


38


39


40


41


42


43


44


45

Why we chose this OLED:

This specific OLED has a plethora of features that we found imperative to our design.

SPI Communication:

o The first and foremost was the SPI communication. Since our main microcontroller will

be communicating to all its slaves via SPI, we needed the GUI to follow suit.

o It offers 3-wire and 4-wire SPI, both of which can work with our microcontroller

Integrated PCB:

o With an integrated PCB, we did not have to communicate directly to the 400+ pin layout

of the onboard SSD1332

Simple 16 pin interface

Perfect Size:

o With a 3.2” display, this OLED was just big enough to get all the necessary information,

but not too large.

Draws low power

Not too big to fit on arm module

Affordable Cost:

o At only $37 (including shipping) this was a cheap addition to the project

Soft Color:

o The yellow display color is a relatively neutral color that is soft on the eyes and fit our

color scheme.


46

Budget

Figure 30: Quarter 1 Budget

Fu

nd

ing

So

urc

es

Am

ou

nt

5C

ITR

US

$600

Taylo

r Furta

do

$156.6

7

Baskin

School o

f Engin

eerin

g$500

Kyle

Law

rence

$122.2

2

Ivan R

om

ero

$130.3

2

Mic

hael S

it$79.1

0

Ale

x Lyn

chosky

$101.9

6

CIT

RU

S$96.6

9

To

tal

$1,1

00.0

0B

askin

$323.9

5

Estim

ate

d T

ota

l$2,1

64.2

4$969.2

7

Estim

ate

d C

ost p

er P

ers

on

$212.8

5$0.0

0

Estim

ate

d F

un

ds A

vaila

ble

-$1,0

64.2

4$130.7

3

Item

Descrip

tion

Pric

e (P

PU

)Q

tyS

ub

tota

lT

ax

Sh

ipp

ing

Estim

ate

d C

ost

Actu

al C

ost

Diffe

ren

ce

Muscle

Sensor v3

Kit

50.0

0$

2$100.0

0$8.7

56.0

0$

$114.7

5$54.3

4$60.4

1

EM

G C

able

s &

Pads

55.0

0$

1$55.0

0$4.8

17.0

0$

$66.8

1$52.4

4$14.3

7

Alb

erta

PC

B50.0

0$

4$200.0

0$17.5

030.0

0$

$247.5

0$74.5

8$172.9

2

IC S

EN

SO

R T

HE

RM

OP

ILE

5.0

0$

2$10.0

0$0.8

83.0

0$

$13.8

8$4.5

2$9.3

6

Mic

rocontro

ller

20.0

0$

4$80.0

0$7.0

05.0

0$

$92.0

0$92.0

0

Batte

ry60.0

0$

4$240.0

0$21.0

07.0

0$

$268.0

0$64.9

4$203.0

6

Cablin

g5.0

0$

10

$50.0

0$4.3

85.0

0$

$59.3

8$4.9

5$54.4

3

Haptic

s5.0

0$

4$20.0

0$1.7

55.0

0$

$26.7

5$26.7

5

3D

prin

ting m

ate

rial

45.0

0$

2$90.0

0$7.8

85.0

0$

$102.8

8$102.8

8

OLE

D31.0

0$

2$62.0

0$5.4

35.0

0$

$72.4

3$37.2

2$35.2

1

Pre

ssure

Sensors

5.0

0$

6$30.0

0$2.6

35.0

0$

$37.6

3$5.9

5$31.6

8

Moto

rs20.0

0$

6$120.0

0$10.5

05.0

0$

$135.5

0$88.2

7$47.2

3

Moto

r Drive

rs10.0

0$

6$60.0

0$5.2

55.0

0$

$70.2

5$70.2

5

Mis

c. G

ears

40.0

0$

2$80.0

0$7.0

05.0

0$

$92.0

0$92.0

0

Worm

Gearb

oxe

s

60.0

0$

4$240.0

0$21.0

05.0

0$

$266.0

0$242.0

4$23.9

6

Assorte

d H

ard

ware

200.0

0$

1$200.0

0$17.5

05.0

0$

$222.5

0$107.5

6$114.9

4

Bearin

gs

30.0

0$

2$60.0

0$5.2

55.0

0$

$70.2

5$46.2

9$23.9

6

Assorte

d E

lectro

nic

s60.0

0$

1$60.0

0$5.2

55.0

0$

$70.2

5$111.6

3-$

41.3

8

PC

B A

dapto

rs

40.0

0$

3$120.0

0$10.5

05.0

0$

$135.5

0$74.5

4$60.9

6

# o

f Mem

bers

Actu

al F

un

ds A

vaila

ble

Actu

al C

ost p

er P

ers

on

Actu

al T

ota

l


47

References

[1] Open Hand Project: http://www.openhandproject.org/

[2] A Multigrasp Hand Prosthesis for Transradial Amputees.

[3] Military Handbook, Anthropometry of U.S. Military Personnel

[4] Enabling Closed-Loop Control of the Modular Prosthetic Limb Through Haptic Feedback. (John

Hopkins APL technical digest, volume 31, number 4 (2013).

[5] Principles of Non-Contact Temperature Measurement. (RAYTEK, Author: Klaus-Dieter Gruner)

[6] TEMPERATURE SENSORS: ADVANTAGES & DISADVANTAGES (Application Note,

October 2003, www.meas-spec.com)

[7] Thermoelectric Infrared Sensors (thermopiles) for remote temperature measurements; pyrometry

(Jurgen Schilz PhD , PerkinElmer Optoelectronics GmbH)

[8] Tactile Sensing (RM Crowder, January 1998,

http://www.southampton.ac.uk/~rmc1/robotics/artactile.htm)

http://www.openhandproject.org/

http://www.meas-spec.com/


48

Appendix


49


50


51


52


53


54


55


56


57


58


59


60


61


62


63


64


65

M.E.C.H: Motorized EMG-Controlled HandThe system will provide two forms of feedback to the user:...

Documents

Transcript of M.E.C.H: Motorized EMG-Controlled HandThe system will provide two forms of feedback to the user:...