KGCOE MSD Technical Review Agenda

KGCOE MSD Technical Review Agenda P12003 | Dynamic Keyboard | Phase IV

Purpose: A detailed review of the Dynamic Keyboard IV (P12003) MSD Progress/Outlook

Materials Reviewed:

 Project Overview  Latest Engineering Specifications and Customer Needs  Updated concept selection  Risk Matrix  Updated Mechanical Layouts  Preliminary User Guide  System Architecture  EE and ME Progress assessments and recommendations  Data Samples

Additional Objectives:  Propose multiple design approaches  Selection of most feasible and least cost prohibitive design  Determine major milestones/achievements for MSD I  Outline major goals of MSD II

Meeting Topics:

 Brief Project overview  Material Review  Progress Reports (ME and EE Teams)  Question and Answer (suggestions and critique)

Meeting Date: February 20, 2012

Meeting Location: 09-4435

Meeting time: 3:00 pm – 4:00 pm

KGCOE MSD Page 1 of 21 Technical Review Agenda KGCOE MSD Technical Review Agenda

Meeting Timeline Start Topic of Review Required Attendees Time 4:00 Project Background Recap Dr. Debartolo, Prof. Slack Review Updated Customer Needs, 4:05 Dr. Debartolo, Prof. Slack Engineering Specs 4:15 Review Proposed Concepts Dr. Debartolo, Prof. Slack 4:25 Review Updated Risk Assessment Dr. Debartolo, Prof. Slack 4:30 Electrical Design Review Dr. Debartolo, Prof. Slack 4:45 Mechanical Design Review Dr. Debartolo, Prof. Slack

Project # Project Name Project Track Project Family 12003 Dynamic Keyboard IV Assistive Devices Biomedical Systems & Technologies Start Term Team Guide Project Sponsor Doc. Revision 2011-2 George Slack Elizabeth DeBartolo  New design, drawing, and Project sketches  Relevant test data proving Description functionality of end product Project Background: Expected Project Benefits: When speaking and signing, thought and  Keyboard will benefit the deaf expression are combined to add clarity and community expression. Text entry, however, lacks much of  Keyboard will serve as a basis the expressive power of speaking and signing. for future computer science related senior NTID students support the idea of adding design projects “imposed expression” to the keyboard. From a technology perspective this has little if any impact Core Team Members: to the design requirements. Regardless of the  Doug Hemink – Project end application, the hardware developed in this Manager (ME) project will add another dimension of user input  David D’Allesandro (ME) to a PC.  Devin Blau (EE) Problem Statement:  Michelle Sadallah (EE) The primary objective of this senior design team is to improve both the functionality, reliability, and aesthetics of the existing dynamic keyboard Strategy & developed in phase 3. The dynamic board will capture information about the key being struck as Approach well as force applied to that key, which will feed that information to the PC using a USB. In Assumptions & Constraints: addition customer testing and presentation is to It is assumed that the current design is both be achieved. functional and able to interface with a Objectives/Scope: standard (Windows OS) PC. After understanding current design and 1. The end product should be physically operations, students will make significant similar in size, shape and weight of a design modifications to the current phase II standard keyboard. keyboard relevant to housing and integrated 2. The keyboard must be capable of electronic components. Proposed budget: returning character input in conjunction with $300 or at the recommendation of the team stroke pressure and time of contact (paired and sponsor. information). 3. The keyboard must be capable of Issues & Risks: providing accurate and consistent data.  Full range of components will not fit in a Deliverables: standard keyboard shell  Upgraded functional keyboard  Lead time for printed circuit board may that meets project needs be longer than expected  Thorough testing by team and  Must consider cost when designing end-users. Gather end-user feedback for keyboard future keyboard project needs.

Dynamic Keyboard Phase IV: Customer Needs

KGCOE MSD Page 4 of 21 Technical Review Agenda KGCOE MSD Technical Review Agenda Dynamic Keyboard Phase IV: Engineering Specs Customer Importance Description Comments/Status Need # (1=Low) Ability to portray expression through Enhanced via electrical sensors within CN1 9 learned ability the keyboard Integration to PC through standard CN2 9 PS/2 or USB connections Ability to differentiate individual key Maintain the integrity of the sensor CN3 9 strike events, and associate them to work done by previous group when corresponding sensor events in time. applied to complete keyboard. Keyboard functions as a regular CN4 9 Simple keyboard functionality keyboard without any special software or installation (mechanical threshold) CN5 9 Must be reliable Thorough testing with user feedback Establish a high level of device CN6 9 Low error margin precision Design or consider other keyboard Need to meet with ID students, NTID CN7 9 configurations for future teams students, and faculty Minimize size to a standard CN8 3 keyboard size Reduce complexity & CN9 3 Minimized end user cost. parts/manufacturing costs CN10 3 Device durability Through normal use (part integrity) Critical failure (spilled drinks, being CN11 3 Device durability II dropped etc.) Weight is not in excessive range with CN12 3 Portability added parts Monthly maintenance or less on CN13 3 Low maintenance average Easy to fix for common problems & CN14 3 Ease of maintenance normal wear CN15 3 Within budget constraints Goal is less than $1000 Separate number pad similar to CN16 3 Keyboard contains number pad standard keyboards CN17 9 Linear tactile feedback Feels like a keyboard CN18 1 Ergonomics Comfortable use Modern/Contemporary look & CN19 1 Aesthetics materials CN20 1 Sensors in number pad Sensors in keys that can easily be given extended functionality to provide CN21 1 Expanded functionality a more dynamic interface outside of the emotional context.

Implant USB Hub to run singular cable CN22 1 Single cable keyboard connection out

KGCOE MSD Page 5 of 21 Technical Review Agenda KGCOE MSD Technical Review Agenda Work Breakdown Structure:

Engr. Specification Unit of Marginal Ideal Spec. Importance Source Comments/Status (description) Measure Value Value # CN18 Keystroke has Maintain natural ES1 9 CN17 CN4 Tactile Feel Boolean No Yes keyboard feel

Keys withstand Max force Will be checked as ES2 9 CN5 CN10 Force (N) 6 10 proper value Total component Dollars Don’t foresee large ES3 9 CN9 CN15 costs ($) 1000 <300 costs Weight ES4 1 CN12 Keyboard Weight (lb.) 5 2 Keyboard Cables Cable Possible Solution in ES5 3 CN22 Required Quantity 2 1 Works Respond to 0N to Force Response 10N of force (0 to ES6 9 CN6 Range Force (N) 0-3 0-10 2.25lb) Voltage (V) Current 5.00V 5.00V ES7 3 CN2 Powered via USB (mA) 500mA 200mA Done ES8 3 CN6 Resolution of Output cycles 3 10 Precision of force Sensor ES9 9 CN6 sensor %error ±10% ±5% repeatability Minimum duration ES10 3 CN3 detection ms 30 5 At 120 WPM Less than 10ms assumes Minimum frequency simultaneous key ES11 1 CN3 detection Hz 5 10 strikes Overall Keyboard ES12 3 CN12 thickness cm 7.5 4 Minimum Cable Current design ES13 3 CN12 Length m 1 1.5 choice in question CN5 CN10 ES14 3 CN13 Keyboard Durability Years 1 3 Average use If resolution good enough benchmark ES15 1 CN6 Signal to Noise Ratio 10:1 100:1 might shift Not sure if ES16 9 CN2 Keyboard drivers - New Original possible ES17 3 CN8 CN19 Keyboard Width Cm 56 46 Within Reason ES18 3 CN8 CN19 Keyboard Length CM 27 17.8 Within Reason CN7 CN2 Type of PC ES19 9 CN4 Interface Type Other USB Done? Paired Character ES20 9 CN1 Data Boolean No Yes Reversible ES21 1 CN14 Construction Boolean No Yes CN20 CN 21 ES22 1 CN16 Number of keys # 80 105 105?

KGCOE MSD Page 6 of 21 Technical Review Agenda KGCOE MSD Technical Review Agenda Dynamic Keyboard Phase IV: Proposed Concepts (further detail in Mechanical Assessment Section)

Dynamic Keyboard Phase IV: Proposed System Architecture

Modified Original Feedback Sensor Internal User Input Keyboard Hardware Casing Keys Mechanism Martix Frame System

Mechanical Stop (threashold) Sensor Micro USB Hub PC Controller Controller

Original Original Keyboard Controllor Membrane

Dynamic Keyboard Phase IV: Risk Assessment

Electrical Team Assessment:

 Prior team issues have been eliminated primarily through mechanical upgrades as well as data manipulation (Ghosting) o No loss in data resolution just being sorted to be more effective  Prior team assumptions for “best capture conditions” (e.g. Minimum thresholding) may not be ideal  Arduino sampling rate is currently being limited by the code o It is still unknown if this is the threshold of the processor o Code is compiled from multiple users/languages . Difficulty in reverse engineering . Have to reflash the arduino  Current sample rate outputs data every 3 milliseconds. (.03 seconds) o This provides 3 samples at the assumed 10 characters per second entry rate . This rate is questionable given required typing style to accommodate DK4 . As the character rate decreases sample rate increase dramatically . As resolution from sensors increases the chances of getting a large variation in “peak force” is questionable  The assumption that the force rises to a peak may not be true  If the peak to nonpeak variation is minimal it won’t cross the “force thresholds” o Current data collected shows trending toward capture accurate data and force readings o Trained typing style could include consistent keypresses  Force sensors seem to have varying lifespans/sensitivities o No spare parts to do life testing o Replacements are costly ($6 per sensor last purchase)  LEDs currently not really providing any accurate stimuli o Code based due to lacking levels?  Suggestions: o Mechanical upgrades continue to increase data resolution . Until upgrades complete doesn’t seem like major electrical overhaul required . Working product that is reliable o Sample rate seems to be sufficient, but there are multiple avenues to seek increased speed . Code overhaul  Copious amounts of code to be dissected and then improved if possible . 2nd Arduino  PCB currently designed only for single arduino  Space issue  Combination of data from each arduino  Possible to Sensor matrix read by two chips?  Budget  Lead time . Replacement of arduino  PCB and electrical system designed for current processor  Power consumption  Budget  Lead time KGCOE MSD Page 14 of 21 Technical Review Agenda KGCOE MSD Technical Review Agenda

 Have to generate all new code

Mechanical Team Assessment

 Keyboard Modifications: o Backside enclosure redesign . Issue: Old backing allowed for PC board to flex which caused ghosting . Solution: Replaced over complicated custom backing with simply modified stock backing . Outcome: Ghosting eliminated in all keys except for those on outer edge of keyboard

Old Backing

New Backing

o Alignment washers . Issue: Ghosting still present in keys along outer edge because PC board was not fixed in place with respect to the face plane allowing the pressure sensors and keys to become un-aligned (major issue) . Solution: Added custom sized washers to hold board in fixed location . Outcome: All ghosting eliminated with the elimination of degree of freedom

Old (D.O.F. = .2”) New (D.O.F. = 0)

 Suggestions: o Improving Current Design

. Currently the key layout is the same as shown above minus the foam insert. The current mechanical translation of key press force is very small compared to the actual force itself. Adding a foam insert or a small ball bearing as shown above would greatly improve this lack of translation of force.

. This solution could potentially increase the problems of “ghosting” just as our first prototyped solution did however it seems less likely using individual foam pieces or ball bearings for each dome.

. This solution would be very inexpensive

o Redesign using silicone keypad

. Utilizing the current IO board and force sensor matrix a custom silicone keypad would be designed to cover the electronics and give a better force translation from key to key without creating issues with ghosting.

. By modifying the snap ratio, as defined by the equation below, the silicone pad can be designed to maximize the translation of force from the key press to the sensor. This would allow the user to potentially type more similarly to their regular typing rather than having to exert a much larger force on the keys.

. A Silicone Keypad also gives the keyboard a more modern feel and look however has the potential to be costly.

 Testing:

o Current Human Generated Test Data:

o Future Testing . Test stand to replace human generated data. Allows for repeatability and normalization of force generated per key.

Concept Proposal #1: Pneumatic Cylinder

Proposed Design Mock Up

Concept:

Utilizing a pneumatic cylinder allows a large range of forces to be achieved by varying only air pressure and allows for a finger strike action. By building air pressure and releasing it into the cylinder the piston will be forced downward to strike the force gauge. Utilizing a cylinder gives the ability to calculate the outputted force and repeat the process multiple times with the same output.

Basic Calculations:

F = p A = p π d2/4 F = force exerted (N) p = gauge pressure (N/m2, Pa) A = full bore area (m2) d = full bore piston diameter (m)

Using this formula a correlation between force and pressure can be predicted. Because the goal is to be able to sense 3 different thresholds of force the pressure can be varied to achieve these different force thresholds. These forces can then be applied to each key (multiple times per force) and then the data can be averaged and normalized.

Concept Proposal #2: Spring Loaded Concept: Utilizing a readily available cordless screwdriver and cheap springs, we can repeate a known force to the key component. The screw driver would be used to disable the applied force of the arm mechanism, allowing for a reapeated test at a constant set force applied. To change the applied force there are two simple options. Option 1: We can design the arm mechanism to have a variable height, therefore applying a different force to the key deponding on the deflection of the spring. This option would only require one spring to be used but would add complexity to the arm mechanism. Option 2: Using a fixed hieght arm mechanism with different springs. The differense in spring constant would allow us to vary the applied force by changing out the spring. This option would seem to be more feasable in comparison to option 1 being that springs are reaosnly inexpensive, it would also eliminate any error posed within changing of arm mechanism height.

Basic Calculations:

Fs = k z

Fa = Fs (xs/xa)

Fs = spring force exerted on arm (N)

Fa = applied force to key (N) k = spring constant (N/m) z = spring deflection when key is at bottom stroke (m)

xs = distance from axis of rotation to point of spring force (m)

xa = distance from axis of rotation to point of applied force (m)

KGCOE MSD Page 21 of 21 Technical Review Agenda