Re: ENSC 440 Design Specifications for a World of Warcraft Input Device

Transcription

1 March 8, 2007 Lakshman One School of Engineering Science Simon Fraser University Burnaby, BC V5A 1S6 Re: ENSC 440 Dear Mr. One, The enclosed document,, outlines InDev s decisions on the design specifications of a device that would improve the comfort and health of World of Warcraft players. If you have any concerns or questions regarding this document, please contact me by at ensc440@gmail.com or by telephone at Sincerely, W. William Walczak, CEO InDev Corp. Enclosure:

2 Project Team: W. William Walczak Vijay Galbaransingh Calin Plesa Contact Person: W. William Walczak Subimitted to: Lakshman One Steve Whitemore School of Engineering Science Simon Fraser University Issue Date: March 8, 2007 Revision: 5.0

3 2 Executive Summary The mass adoption of gaming amongst all age groups suggests that the gaming input device market is ready for young and ambitious engineers. We plan to fill the void that is a comfortable, ergonomic and natural gaming device and bridge the gap preventing all people interested in playing games but unable to with the current desktop setup. The World of Warcraft phenomenon provides the ideal gaming audience for a project that would give us an opportunity to attempt both. The Input Devices (InDev) team has been working on the World of Warcraft input device for over a month, now coined InDevil. The development of InDevil will occur in two phases. The completion of the first phase will produce a device that will be usable for gaming and allow for easy interfacing with the gaming environment. The InDevil will have the following features: 1. Wireless connectivity with the gaming computer. 2. Ability to control the gaming environment without the confines of a twodimensional desktop. 3. Easy integration with the host computer. After the second and final stage of development InDevil will also: 4. Have a comfortable and ergonomic case that is easy to orient without visual inspection. 5. Be a fully usable consumer device. 6. Perform as a reliable consumer device. The first phase of development of InDevil will be completed by May 2007.

4 3 Table of Contents Executive Summary... 2 Table of Contents... 3 List of Tables... 5 List of Figures... 5 Revision History... 6 Introduction... 7 Scope... 7 Acronyms... 7 Intended Audience... 8 Remote Interface... 8 Ergonomics... 8 The Interface and Layout... 9 Overview... 9 Physical Layout... 9 Functions WoW UI functions: Physical Requirements Electronic Specifications System Hardware Overview InDevil Remote Hardware Motion Sensors IDG 300 Dual Axis MEMS Gyroscope ADXL330 Triple Axis Accelerometer IMU 5 DOF Breakout Board Microcontroller Zigbee XBee Wireless Module USB Dongle Hardware Other Hardware Power Supply Buttons and Casing Prototype Hardware vs. Production Device Hardware InDevil Firmware and Drivers Firmware Compliance Human Interface Device (HID) Movement Mouse Buttons Action Buttons Button De-bounce Firmware Logic Flowcharts Testplan... 29

5 4 Testing Figures of Merit - Gauging Usability Improvement Overview Gyroscopic Mouse The InDevil World of Warcraft Interface Hardware Testplan Conclusion Sources and References Appendix A... 32

6 5 List of Tables Table 1 Movement Table 2 - Actions (typically located on the Action Bar in the default WoW UI) Table 3 - Comparison between available gyroscope chips Table 4 - Comparison between available accelerometer chips Table 5 - Structure of a data packet Table 6 - The current drawn from various remote components List of Figures Figure 1- Finger Anatomy [1] Figure 2 - Top view with natural thumb position Figure 3 - Bottom view with natural finger positions Figure 4 - Index finger with intended button movement and position Figure 5 - Middle and ring finger with intended button movement and position Figure 6 - Pinky finger with intended button movement and position Figure 7 - High Level Block Diagram of the System Figure 8 - The IDG300 chip Figure 9 - The ADXL330 chip Figure 10 - Inertia Measurement Unit Combo Board with the IDG300 and the ADXL Figure 11 - Circuit Schematic for the InDevil remote Figure 12 - USB Enumeration and HID communication flowchart [9] Figure 13 - Remote side firmware interrupt driven logic flowchart Figure 14 - Remote side firmware button polling and transmission logic flowchart Figure 15 - Dongle side firmware logic flowchart... 29

7 6 Revision History Revision Date Description Name 1.0 Feb 19 Initial Version Calin Plesa 2.0 March 3 Remote Interface Calin Plesa 3.0 March 4 Hardware Calin Plesa 4.0 March 8 Calin Plesa William Walczak Vijay Galbaransingh

8 7 Introduction There has been an attempt in the past to provide gamers on the personal computer (PC) platform an alternative to the regular mouse and keyboard input device combination. However, this combination has proven to be superior to every substitute and a viable alternative has proven elusive. The current input devices used for World of Warcraft are the traditional keyboard and mouse. The keyboard is a combined input device that is used for both action buttons and character movement. The mouse is used to interface with onscreen controls, the WoW environment, and repositioning of camera angles. The goal of this project is to redesign the interface in such a way that will reduce strain, allow for a more comfortable body position and allow the player to game for longer and not suffer any long term effects of strain. Scope This document is the design specification of the implementation which can meet the functional requirements that must be met by a functioning InDevil World of Warcraft Input Device. A full set of design specifications is supplied for the prototype device. The document also discusses expected differences between the prototype and the expected production model. The requirements listed here drive the design of the InDevil and will be traceable in the design documents. Acronyms Acronym ADC EEPROM EVB HID ISM LDO MCU NiMh OS PAN PDIP RF UI WoW Definition Analog to Digital Converter Electronically Erasable Programmable Read Only Memory Evaluation Board Human Interface Device Industrial, Scientific and Medical Low Drop Out Microcontroller Unit Nickel Metal Hydride Operating System Personal Area Network Plastic Dual Inline Package Radio Frequency User Interface World of Warcraft

9 8 Intended Audience This document is to be used as a reference point for the design engineers working on the InDevil. Management will be able to refer to this document to determine the progress of the design engineers and gauge whether the design cycle is on schedule. Investors will be able to compare the InDevil to competing input devices currently in development using this document. Marketing will be able to use this document to develop promotional material. Remote Interface Ergonomics A key goal of the remote is minimizing the risk of repetitive strain injuries (RSI) and developing a device that is as comfortable to use as possible. Ergonomic considerations form the basis for the implementation and layout of the InDevil remote. All buttons therefore must be placed in such a way as to have minimal movement of the fingers from their rested and natural position (with the exception of the thumb.) Also, actuating any buttons or functions must not require great force of effort, or the use of any weak areas of the finger. As such, the following guidelines have been followed for all buttons placed for use by fingers other than the thumb: rely on depressions by only the middle and distal phalanxes require little lateral movement of the finger only curling or outstretching no button actuations necessitate full extension of the finger with the middle knuckle locked all actuations keep the joint soft and maintain strength the majority of actuation required by the player in normal use of the device will be confined to the thumb, index, and middle fingers use of the pinky finger must be minimized A further set of design constraints applies to wrist and arm positioning since the InDevil will use both rotation and linear motion in its implementation: the majority of normal use of the device must be possible in a seated position with the arm rested on a chair arm or the player s lap the arm and elbow must not be in outstretched positions for any appreciable length of time no device functions will require exertion of great force, or throwing of the limbs no device functions will require complex sequences of movements At the time of this revision, the InDevil interface design is pending review by an ergonomic professional on Friday, March 9, 2007.

10 9 The Interface and Layout Overview The InDevil performs the following functions, allowing the single one-handed remote to completely control World of Warcraft under all situations: Cursor movement and mouse buttons/scrolling Character movement Character actions Warcraft interface functions Cursor movement is handled by the use of a MEMS gyroscope (the IDG-300), with replacements for mouse buttons and the scroll wheel placed on the remote. Character movement is implemented by a region under the thumb whose operation mimics that of a directional pad on a standard video game controller. Character actions are implemented by depressing designated action buttons or depressing an action button and simultaneously moving the InDevil along any of the 6 cardinal directions in 3-D space (accelerometers detect this motion.) Finally, various Warcraft interface functions (such as opening one s backpack or mounting a horse) are implemented by designated trigger buttons on the InDevil, which are operated in the same manner as action buttons. All of the device s action and trigger buttons are re-configurable by the player through the Warcraft options menu should he so choose, since the device simply appears as a generic Human Interface Device (HID) to the operating system. Physical Layout The InDevil senses rotation and linear motion, and has sets of buttons. The buttons can be categorized as Mouse, Directional, Scroll, Trigger, or Action buttons. The following button shorthand will be used in describing InDevil actions: M(x): Mouse Button x D(x): Directional pad button Up Down Left Right S(x): Scroll Wheel Up Down T(x): Trigger Buttons 1, 2 or 3 A(x): Action Buttons 1-6, where Axy indicates a combination U/D/L/R/F/B: Respective Up Down Left Right Forward Backwards (toward user) on accelerometer axes Combinations are indicated by X + Y, for example A1 + U means to press Action button 1 while moving the remote upwards. Figure 1 is an illustration of the human hand for referencing of the anatomy of the finger.

11 10 Figure 1- Finger Anatomy [1] Figure 2 through Figure 6 illustrate the layout of the remote, the placement of buttons, and the fingers intended to access the buttons. Figure 2 - Top view with natural thumb position Figure 2 shows the front of the InDevil with the buttons the thumb will access. The region with four separations under the thumb is D1-D4, implemented by means of a thumb pad aligned vertically with the thumb s neutral resting position. The shape will be as a recessed oval cusp with regions for the four directions. The two buttons to the left are T1 and T2, which are tilted with respect to D1-D4 in their alignment, but at the same horizontal level. The button to the right is the scroll wheel, which can be pressed down for M3. The scroll wheel shall also be tilted to allow the thumb to actuate it moving only up and down when pointed in that direction, requiring no diagonal compensation by the player.

12 11 Figure 3 - Bottom view with natural finger positions Figure 3 shows the back of the InDevil. The index finger is covering M1 and M2. The middle finger presses buttons A1-A3 (numbered left to right) and the ring finger presses buttons A4-A6. The pinky accesses T3. Figure 4 through Figure 6 show the parts of the finger that will contact the button, with illustrative side profile views for the necessary shaping of the buttons and remote casing surface. Figure 4 - Index finger with intended button movement and position

13 12 The middle and distal phalanxes of the index finger will press M1 and M2. The curvature allows and easy M1 + M2 combination by squeezing the whole index against the remote. Figure 5 - Middle and ring finger with intended button movement and position The middle and ring fingers will access A1-A6 using the distal phalanx. Two button combinations such as A14 (the first button of each row) will have both fingers acting this way. The two possible three button combinations are A123 and A456, achieved by squeezing either the entire middle or ring finger against the remote to press the whole row. The last combination that will be used in the InDevil s intended operation is A squeezing both the middle and ring fingers against the remote. None of the combinations described are elaborate nor require individual fingers to move separately at the same time the middle and ring fingers either move individually, or together as a unit. The buttons protrusions are a bit exaggerated in the diagram they should actually be reasonably flat on a convex surface so that they are easily located by tactile sensation, and easily pressed in combinations.

14 13 Figure 6 - Pinky finger with intended button movement and position The pinky accesses T3 by pressing down with the distal phalanx and the distal interphalangeal joint. T3 must be a fairly oblong button so that the pinky can still act to stabilize the remote in the player s palm while easily pressing the button. Functions Normal movement of the mouse cursor will be accomplished by rotating the wrist side to side or up and down. No buttons are involved other than M1, M2, or M3 which perform their normal functions as dictated by the default World of Warcraft User Interface (WoW UI.) SU and SD also behave as expected on a normal mouse. Following are categories of functions and the default configuration for performing them. Table 1 Movement Move Forwards or Backwards Turn Left or Right Jump DU or DD DL or DR U Table 2 - Actions (typically located on the Action Bar in the default WoW UI) Actions 1-6 Actions 7-9 Actions Action 12 A1,A2,A3,A4,A5,A6 A14,A25,A36 A123,A456 A Actions beyond the standard 12 are performed by pressing any of the action buttons and moving the remote quickly but gently along the cardinal directions (for example A1 + F,)

15 14 allowing for 72 possible additional actions. The purpose of this design is to provide quick and easy access to the first 12 functions (which are most used) so that all players can control the game without needing the keyboard, while allowing more advanced players who prefer using a keyboard shortcut instead of clicking icons in the WoW UI to replicate this functionality by having access to a vast number of functions on the InDevil without resorting to more than 6 buttons to access all of them. WoW UI functions: The interface functions such as enemy targeting, special abilities, mounts, etc. can be bound to T1 and T2, as well as combinations of either with movements, for example T1 + U. It is intended that T3 will be used for voice chat applications such as TeamSpeak or Ventrilo. Physical Requirements 1. The casing for the remote shall be a form fitting plastic case, with dimensions less than 6cm wide, 15 cm long, and 6cm thick, so that it may fit comfortably in a typical user s hand. 2. The casing for the remote shall have a bay on the back with a removable cover to place a battery. The bay size shall be less than 3cm x 4cm. 3. The remote shall weigh no more than ½ lb. 4. The remote shall use a standard scroll wheel with depression click from a mouse. 5. All mouse, trigger, and action buttons shall be approximately 1.5cm 2 in area (with the exception of T3 which can be up to 2.5 cm 2 ) and require no more force to press than standard mouse buttons. 6. The buttons shall be placed on the remote as described under Physical Layout so the correct and intended parts of the finger press them. 7. Those buttons which appear in close proximity to each other (i.e. A1-A3) shall have distinct shapes to enable tactile determination by the player of which button he is touching. For example A1 and A3 could be shaped as semi circles, with A2, being in the middle of A1 and A3, shaped as a square. Electronic Specifications The physical specifications of the device necessitate a solution with the following minimum specifications: binary inputs for buttons 2. 5 Analog to Digital channels (2 for the gyroscopes, and 3 for the accelerometers) 3. Wireless communication with computer 4. Baud rates and computation speeds must be fast enough for the interface to appear instant to the user as a keyboard or mouse do 5. Portable power source a. Provides supply voltage required b. Sustains power for at least seven consecutive six hour play days (42 hours) 6. Remote must enter and exit power saving modes without any user command

16 15 System Hardware Overview The InDevil consists of two separate physical devices. The handheld unit detects the user s actions and transmits the data wirelessly. The second device is a USB dongle which receives the data and passes it to the computer in the HID format for system driver recognition. Figure 7 - High Level Block Diagram of the System Hardware was selected based on the following criteria, in order of importance: 1. Features and Performance 2. Packaging Many components came in surface mount or ball grid arrays which are beyond our prototyping facilities. Therefore, only PDIP or through-hole components were selected for this stage. 3. Ease of use Modules were selected that were easily interfaced to other components and minimized tedious circuit design and construction (i.e. pull-up resistors, capacitors.) 4. Availability Given our tight schedule, we could not afford to wait more than a week or two. 5. Price In evaluating prospective technologies, the production cost of a module was the most important factor. Although we have chosen certain off the shelf solutions to gain a development time advantage, all modules chosen can be built from basic parts and our own designs. For example the XBee costs $28 per unit however our own Zigbee module built from an Atmel transceiver and our own reference design could be produced for around $5 in volume.

17 16 InDevil Remote Hardware Motion Sensors IDG 300 Dual Axis MEMS Gyroscope The rotational motion of the device will be measured by a dual axis MEMS gyroscope chip. The IDG300 is able to measure rotational motion of up to 500 /sec with a sensitivity of 2mVs/º. [2] Figure 8 - The IDG300 chip. The chip outputs the measured rotation as a corresponding voltage on each axis output. This is output is passed to ADCs on the microcontroller unit (MCU). The output has a +/- 1V swing around the zero-state output (specified in the datasheet as approximately 1.5V.) The gyro will exhibit some drift of the zero-state output, which will be addressed in our firmware implementation. Before the chip was chosen, a comparison was made between the chips that could be used. Although the Analog Devices ADIS16100ACC has a digital output, there is no dual axis version available, meaning that two chips would be needed. We decided to use the IDG300 primarily because the cost of implementation would be nearly three times smaller than the other option.

18 17 Table 3 - Comparison between available gyroscope chips IDG300 ADIS16100ACC Dual Axis MEMS Gyro Single Axis MEMS Gyro Manufacturer Invensense Analog Devices Number of Chips Needed 1 2 Cost (Prototyping) Total Cost (Prototyping) Range +/-500 /s +/-300 /s Sensitivity 2mV/º/s 4.1 LSB/ /s Operating Voltage 3V 5V Output Analog Digital ADXL330 Triple Axis Accelerometer The linear acceleration of the device will be detected using the ADXL330 triple axis accelerometer chip. The chip can measure +/- 3g of acceleration along each of the three axes with a sensitivity of 300mV/g [3]. As with any accelerometer, the chip cannot distinguish between linear acceleration and gravity. This will be overcome by ignoring all movements below a certain empirically determined threshold. Figure 9 - The ADXL330 chip. The two main triple axis accelerometer chips available were compared. The ADXL330 was chosen due to the lower cost of the chip, lower power requirements, and the

19 18 availability of an off the shelf module containing both the gyroscopes and accelerometer (detailed in the next section.) Table 4 - Comparison between available accelerometer chips ADXL330 LIS3LV02DQ Manufacturer Analog Devices STMicroelectronics Range +/- 3 g +/- 6 g Sensitivity 300 mv/g 340 LSb/g Current 0.32mA 0.65mA Cost (Prototyping) Output Analog Digital IMU 5 DOF Breakout Board For the prototype unit we will be using the Inertia Measurement Unit Combo Board made by Spark Fun Electronics. This board contains both the IDG300 and the ADXL330 on a small 20 x 23 mm board [4]. The board will be connected to the microcontroller board using a standard 9 pin 2.54 mm straight header shown in Figure 10. The use of the IMU 5DOF also allowed us to bypass the surface mount limitations of the IDG300 and ADXL330 by providing a breakout board. The board is driven by a 3.3V supply from the microcontroller board. This will be passed through a LDO adjustable voltage regulator in order to meet the supply requirements for the IDG300 chip. It should be noted the ADXL330 has a ratiometric output that is proportional to the supply voltage. The use of a voltage regulator will ensure that the voltage remains stable throughout operation. The accelerometers outputs are bandwidth limited to 50Hz. Since the sampling frequency of the ADCs is much higher there will be very little aliasing. This limiting will also help filter out noise.

20 19 Figure 10 - Inertia Measurement Unit Combo Board with the IDG300 and the ADXL330 Microcontroller The Atmel ATmega32L is an 8-bit AVR microcontroller that meets all of the relevant electronic specification requirements outlined earlier. The unit has eight 10 bit ADCs and 24 other I/O pins [5]. The low power version of the chip can run at 3.3V, meaning that we can run all of the components of the handheld device using the same power supply. The ATmega32 also has 32K Bytes of In-System Self-Programmable Flash, 1024 Bytes EEPROM, and 2K Byte Internal SRAM. The ATmega32L was chosen over other alternatives for its superiority in the following areas: Number of I/O lines and A/D channels Ultra-low power consumption Quality of freely available development tools (AVRStudio and WinAVR) Availability of libraries and community support Portability of code across the entire selection of 8-bit AVRs Implementation of UART (since the XBee communicates via UART, and absence of this feature would have meant implementing the UART protocol in firmware) MCU programming will be done using a JTAG interface which will be built into the circuit using a 2x5pin header. The ATmega32L used will come in a 40 pin PDIP package which will be placed in a DIP socket. The socket leads will be soldered to the protoboard which will hold all of the

21 20 components needed for the MCU as well as connectors for the wireless module and the motion sensor breakout board. Although the ATmega32 has a built in oscillator, an external oscillator will be built on the protoboard using an 8MHz crystal and two 22 pf caps. Figure 11 - Circuit Schematic for the InDevil remote Zigbee Zigbee is a wireless standard based on IEEE It provides for the development of low power medium bandwidth wireless devices that self-associate in PAN configuration. Zigbee as a technology was chosen over other options for the following reasons: Low power consumption Low cost (compared to Bluetooth) Minimalistic architechture Integrated error checking and device association ISM band (unlicensed radio traffic)

22 21 Availability of plug and play modules (other options would have required RF circuit development which would significantly increase development time) Among the available off the shelf Zigbee modules the XBee was selected because it was relatively low cost, readily available, well documented, featured UART implementation (to facilitate MCU communication) and integrated an on-chip antenna. XBee Wireless Module The XBee is a wireless module operating in the 2.4GHz ISM bands using the Zigbee protocol. It has a range of up to 30 m with a transmission power of 1mW [6]. The module is capable of a maximum data rate of 250kbps. The XBee communicates with the MCU using UART. Data is sent through the UART in 8 bit packets. The XBee stores this data in a buffer before it is sent out. When there is no wireless link active, the XBee will try to establish a link and then go into 2 sec periods of sleep. This will help reduce power consumption while the device is not in use. The XBee can enter and exit sleep mode in a maximum time of 12 ms. The XBee module has non-standard 2 mm spacing on its output pins. This is accommodated through the use of 2 mm pin receptacles on the protoboard. The transmission scheme used will send 13 byte data packets with a 3 byte starting header. The dongle will benefit from the header so it may interpret incoming data. Table 5 - Structure of a data packet Component Data (bits) (bytes) X Gyroscope Y Gyroscope X Accelerometer Y Accelerometer Z Accelerometer VRef Buttons + Scroll Wheel Diagnostic Code 2.25 Total Data 80 bits 10 bytes Header 24 bits 3 bytes TOTAL Packet Size 104 bits 13 bytes

23 22 USB Dongle Hardware The USB dongle which receives data from the handheld unit consists of an XBee module and an AT90USBKEY development board. The AT90USBKEY has an AT90USB1286 microcontroller which is similar to the ATmega32 but has a variety of USB functions built in. The dongle microcontroller will be programmable directly through USB using a preloaded USB boot loader [7]. The AT90USBKEY was chosen for the following reasons: Hardware implementation of the USB protocol Cheap evaluation board Same development tools and fundamental functionality as the MCU for the remote since the AT90 is AVR based Freely available examples of demonstration code (including application for a HID keyboard) Low production cost Other Hardware Power Supply The InDevil Remote will be powered by three NiMh AA batteries with a capacity of at least 2300mAh each. Table 6 - The current drawn from various remote components Component Current (ma) ATmega ADXL XBee Sleep Idle Transmit IDG TPS7201QP <0.30 Summing the current draw of the major components, we can say with great certainty that the total consumption of the remote will be less than 80mA. Our original requirements that the device be usable for 7 consecutive 6 hour long sessions (which would outperform other wireless game controllers such as the Wii-mote) would, at this level of current consumption, require a battery capacity of 3360 mah in the worst case. By taking advantage of the power down mode on the XBee (which is responsible for the largest power consumption) we may conceivably achieve power savings of 50% or greater. The following considerations are the most important when considering what type of battery to use: Size and weight

24 23 Cost of supplying a battery in production (or cost to the consumer of procuring their own) Cost of a charger Voltage output Given these requirements in addition to the capacity specification, a NiMh battery is the most sensible solution. They are much lower cost than other batteries of this capacity level such as Lithium Polymer Ion batteries (even though Li-Polymer batteries offer size advantages,) and are ubiquitous among consumers for their use in personal electronics (i.e. digital cameras, mp3 players.) The three AA batteries will output a voltage of 4.5V which will be passed into the TPS7201QP adjustable LDO voltage regulator which will output 3.3V. Three batteries will also not significantly strain our requirements on space or weight. The TPS7201QP has been chosen for its ultra-low operating current, availability in PDIP packaging, and because it was designed for portable applications. The dongle s power is supplied by the USB connection. A 5V power pin on the port D connector of the dev board will be passed through a 3.3V voltage regulator and used to power the dongle s XBee. Buttons and Casing A variety of standard mouse buttons have been salvaged from old mice to be used in the remote. Once the minimum area necessary for the remote s protoboard is known we will begin testing different cases which can fit the protoboard, buttons, and the battery pack. Prototype Hardware vs. Production Device Hardware In the production device, all of the components will be integrated onto a single PCB. The production device will not use an XBee but will instead utilize either a Freescale (MC RF transceiver IC) or Chipcon Zigbee IC with an on chip antenna, in both the handheld unit and the USB dongle. The USB dongle will be based around the AT90USB128 chip as in the USB development board. The USB dongle in the prototype is connected to the computer s USB port by a B-A USB wire but the production device s USB dongle will be much smaller and physically plug directly into the type A USB slot in the back of the computer. InDevil Firmware and Drivers The InDevil World of Warcraft input device will function much like any other pointing device utilizing the HID standard that is currently configured to work with a Windows based PC. This means that it will interact with the computer as a USB pointing device.

25 24 The difference will of course be that it will have more buttons and will establish its X and Y coordinates and movements from a gyroscope, rather than the typical optical sensor. The majority of the functionality and compatibility with the gaming environment, WoW, will be handled in the typical way by the operating system. The main gaming platform for WoW is the Windows based PC while a small part of the market is played on the Mac OS X platform. Therefore, the initial focus for development will be Windows compatibility. While compatibility should be guaranteed by the HID standard focus will be given to the Windows platform. Firmware One of the principle motivations for choosing the ATMEL AVR 8-bit microcontrollers was the ability to use C programming as opposed to assembly and the existence of the free GNU WinAVR gcc compiler with a wide variety of useful libraries. The output of which will be used to flash the microcontroller. Using this specific microcontroller is not a limitation for future design decisions as the source code is highly portable and can be recompiled easily for any ATMEL microcontroller we may want to use. Compliance According to the HID specification that the InDevil will completely abide by there are a number of definitions that will allow for the device to communicate data with the OS in ways that will extend the most functionality and minimize workload by eliminating the need for a proprietary driver. The operating systems of interest are only the two capable of running the WoW game environment, namely, Window and Mac OS X. To provide interoperability the device will comply with the HID standard which is fully implemented on both. Human Interface Device (HID) The USB human interface device class ("USB HID class") is a USB device class that describes human interface devices such as computer keyboards, computer mice, game controllers, and alphanumeric display devices. The USB HID class is defined in a number of documents provided by the USB Implementers Forum's Device Working Group. [8] The InDevil will behave as a HID device and it will specifically act as both a mouse and keyboard, upon device enumeration within the USB port of the host computer. That is, when the InDevil dongle is connected to the WoW capable machine it is connected to the operating system and referenced properly to access OS functionality. HID allows for multiple input devices of the same type and function. Therefore, despite the InDevil s

26 25 functionality as both keyboard and mouse it will not hinder regular mouse or keyboard functionality. The user will be able to use all devices concurrently. The flowchart below outlines how the enumeration and HID compliant processing interacts. Host Side InDevil Side Enumeration NO Polling Inverval NO Any Key Pressed YES YES Send request to InDevil Data Available NO New Data? NO Any PC Request YES YES Data Processing Data Processing Figure 12 - USB Enumeration and HID communication flowchart [9] Movement The InDevil mouse movement is done using the Generic Desktop Page (0x01) mouse usage ID (02). These are the standard mouse up/down/left/right movements for the cursor on the screen. Mouse Buttons Once again using the Generic Desktop Page with mouse usage ID the left, right, and middle mouse buttons will be mapped to the InDevil buttons M1-3. These work just like regular mouse buttons with the corresponding designations.

27 26 Action Buttons The tricky part of the InDevil keyboard and mouse linkage is the extra buttons on the device that extend functionality beyond the regular scope of the HID compatible standard. The action buttons will be linked to standard keyboard presses, rather than the expected mouse presses, and therefore will require the Generic Desktop Page (0x01) but refer to the keyboard device with usage ID (06). In order to not impede the regular keyboard functionality the device custom actions will be linked to keys that are not available on the users keyboard, namely the F13-F24 keys. Since the InDevil has 84 different actions that can be mapped to the action keys together with accelerometer movements and WoW doesn t recognize custom inputs, the actions will be implemented through combos of Ctrl, Alt, Shift, and the F13-F24 keys. This gives 84 possible keyboard combos which are not normally available to the user. Button De-bounce The de-bounce of buttons, to prevent multiple registration of a single button press, which is typical with push buttons will be handled algorithmically within the firmware. Specifically, this will be done by ignoring the input from the same button within a time region that typically and mostly eliminates the oscillations that make these buttons record multiple depresses when only a single input was meant to happen. Firmware Logic Flowcharts The firmware is broken into two distinct sections one for the remote and another for the dongle. On the remote side the firmware is responsible for detecting all inputs from buttons, accelerometers, gyroscopes and formatting the data before serializing it and sending it to the XBee through the UART. The firmware will consist of a main logical loop which is always running. The function of this code is to detect button presses and send data when necessary. The code will detect if there is data to send by checking the transmission stack pointer. If the pointer has been incremented it will pass data off the transmission stack to the UART until the pointer is back to the top of the stack. This is shown in Figure 14. A separate logical loop, show in Figure 13, triggered by an ADC conversion completion interrupt will handle updating of the gyroscope and accelerometer data. It will be able to detect if there is rotational motion by comparing the gyro data to the calibrated zero state offset. The accelerometers will be analyzed to see if their outputs are over a given threshold. If the acceleration is over a certain threshold, the buttons will be polled in order to detect the action combos. Whenever motion is detected, the data will be formatted into a transmission packet and be placed on the transmission stack. The transmission stack pointer will be incremented to let the main code know there is data to send.

28 27 Start NO ADC Conversion Complete? YES Adjust for zero state offset Was there movement? NO YES Write Gyro data to memory NO Check if Accelerometer is above threshold YES Check for button presses NO Was combo pressed? YES Write to send stack Figure 13 - Remote side firmware interrupt driven logic flowchart

29 28 Figure 14 - Remote side firmware button polling and transmission logic flowchart The logical flow of the firmware on the dongle is shown in Figure 15. Data which is received from the UART is decoded and analyzed. A HID report is created based on the type of event received. This is sent to the host computer over the USB connection using the HID standard.

30 29 Start Receive UART Data Decode Data packet Determine Event Is it gyro data? NO Is it mouse Press? NO Therefore, must be a Keyboard action YES YES Format into HID mouse movement Format into HID mouse action Format into HID keyboard action Queue HID Report Figure 15 - Dongle side firmware logic flowchart Testplan Testing Figures of Merit - Gauging Usability Improvement Overview At this point it should be re-iterated that the major goals of the InDevil interface design are: Increasing comfort and decreasing risk factors for RSI Increasing usability and player efficiency The first goal will be qualitatively assessed through ergonomic review of the interface and final device, as well as a brief analysis of resulting posture and muscle use or overuse based on basic principles of proper office desktop setup. Quantitative analysis is beyond the scope and timeframe of the proof of concept stage implied in our demonstration

31 30 deadline, although options for developing some quantitative basis for RSI factors will be explored in the evaluation stage following device completion. The second goal however can not only be easily qualified but quantified as well. Gyroscopic Mouse The single greatest departure from conventional input schemes is the use of angular rotation in space as a replacement for mouse cursor control. The simplest and most effective way to quickly build a collection of data to gauge user aptitude at this input mode is a test application (not usage in Warcraft.) Such an application shall consist of a blank background with a series of targets. Test users will be presented with instructions to home the mouse cursor onto a target then move as quickly as they can to another designated target. The total time taken by the user shall be the figure of merit and will be measured by the application. By comparing user performance with the InDevil to the same tests performed using a standard mouse we may measure the efficiency of our air mouse versus a normal mouse. These comparisons will also allow inferences about the effect of removing tactile sensations from the user feedback loop movements in air offer little resistance as compared to dragging a mouse across a table. Conducting the same trials with brand new users as well as experienced users will also give a sense as to the expected learning curve. Both savvy gamers and less capable players will be tested. The InDevil World of Warcraft Interface The next most important test will be the performance of our interface design in-game. We will record observations of players of varying degrees of skill and manual dexterity as they learn (and hopefully master) use of the InDevil. Some quantitative tests such as speed in killing a monster may be possible at this stage, but the most significant determining factors of success will be test subjects feedback and personal assessment of comfort and effectiveness. Video recordings will be preferred, and there will always be one of the project engineers present to aid test subjects. While the help of our team may skew the perceived learning curve a bit, the overall efficiency of a user once they have learned the interface is a more important trait we expect some initial awkwardness. Hardware Testplan All of the hardware will be tested in modular sections before being integrated together. The IMU 5 DOF Breakout Board will be powered up independently and tested by subjecting it to a variety of motions in order to ensure that output characteristics match specifications. If necessary the ADXL330 will be placed into the self test mode to verify the accelerometers are working.

32 31 The ATmega32L s ports will be tested to ensure proper operation. Interfacing the MCU with a computer through JTAG will allow us to verify proper operation. Test the AT90USBKEY using AVR Studio and some test firmware. Test the power supply circuits for the dongle and the remote. Power up both XBee modules and send some test data to ensure proper operation. Conclusion Every day over 8.5 million people risk repetitive strain injury for their World of Warcraft fantasy. The InDevil allows people to derive more pleasure with a more comfortable and ergonomic playing position. Sources and References [1] Kentucky Orthopedic Rehab Team f&catid=11 [2] InvenSense, IDG300 Datasheet [3] Analog Devices, ADXL330 Datasheet [4] Sarkfun Electronics, IMU 5DOF [5] Atmel, ATmega32 Datasheet [6] Maxstream, XBee Datasheet [7] Atmel, AT90USBKEY [8] USB human interface device class [9] AVR271: USB Keyboard Demonstration

33 32 Appendix A Quantity Description Part # Supplier Cost per Unit Sub Total Cost REMOTE PARTS: 2 Xbee Modules XB24-ACI-001-ND DigiKey " headers - 36 pin MALE for 5DOF S1012E-36-ND DigiKey " headers - 9 pin FEMALE for 5DOF S4109-ND DigiKey pin dip socket for AVR A9440-ND DigiKey AVR MCU - low power pdip ATMEGA32L-8PU-ND DigiKey mm receptacle 10pin for xbee 2563S-10-ND DigiKey V LDO TPS7201QP - adjustable ND DigiKey LDO socket 8 pin dip A9408-ND DigiKey MHz crystal X100-ND DigiKey JTAG headers HRP10H-ND DigiKey AA NiMh 2500mAh batteries 1 3 AA battery holder DONGLE PARTS: 1 KIT DEMO FOR AT90USB AT90USBKEY DigiKey mm 2x5 pin headers SAM8205-ND DigiKey cable SAM8221-ND DigiKey BACKUP DONGLE PARTS: 1 AVR MCU ATMEGA32-16PU-ND DigiKey MHz crystal CTX415-ND DigiKey pF caps BC1005CT-ND DigiKey USB B receptacle ED90003-ND DigiKey AVR MCU Samples ATmega32L-8PC Atmel AVR MCU Samples ATmega644V-10PU Atmel 0 0 SUB TOTAL DOF Breakout Board Sense-5DOF Spark Fun Electronics TOTAL 325.7

34

35