Optical Encoder for a Game Steering Wheel

Optical Encoder for a Game Steering Wheel Project Plan: May05-26

Client: Thomas Enterprises

David Thomas Sr., President David Thomas Jr., Vice President

Faculty Advisors: Dr. James Davis Dr. Douglas Jacobson

Team Members: Samuel Dahlke CprE

Peter Fecteau CprE

Daniel Pates EE

Lorenzo Subido EE

DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator. 1 星期一, 五月 07, 2018Table of Contents

1.1 List of Figures iv 1.2 List of Tables v 1.3 List of Definitions vi 2 Introductory Material 1 2.1 Abstract 1 2.2 Acknowledgement 1 2.3 Problem Statement 1 2.4 Solution Approach 1 2.5 Operating Environment 2 2.6 Intended Users 3 2.7 Intended Uses 3 2.8 Assumptions 4 2.9 Limitations 4 2.10 Expected End-Product and Other Deliverables 4 3 Proposed Approach and Statement of Work 5 3.1 Proposed Approach 5 3.1.1 Functional requirements 5 3.1.2 Constraints considerations 5 3.1.3 Technology considerations 6 3.1.4 Technical approach 6

i 3.1.5 Testing requirements 6 3.1.6 Security considerations 6 3.1.7 Safety considerations 7 3.1.8 Intellectual property and commercialization considerations 7 3.1.9 Possible risks and risk management 7 3.1.10 Project Proposed Milestones and Evaluation Criteria 8 3.1.10.1 Proposed Milestones 8 3.1.10.2 Evaluation Criterion 8 3.1.11 Project tracking procedures 8 3.2 Statement of Work 8 3.2.1 Task 1 – Problem Definition 9 3.2.1.3 Subtask 1a – Problem Definition Completion 9 3.2.1.4 Subtask 1b – End-User Identification 9 3.2.1.5 Subtask 1c – Constraint Identification 9 3.2.2 Task 2 – Technology Consideration and Selection 9 3.2.2.1 Subtask 2a – Identification of Selection Criteria 10 3.2.2.2 Subtask 2b – Technology Research 10 3.2.2.3 Subtask 2c – Technology Selection 10 3.2.3 Task 3 – End-Product Design 10 3.2.3.1 Subtask 3a – Identification of Design Requirements 10 3.2.3.2 Subtask 3b – Design Process 11 3.2.3.3 Subtask 3c – Documentation of Design 11 3.2.4 Task 4 – End-Product Prototype Implementation 11 3.2.4.1 Subtask 4a – Identification of Prototype Limitations and Substitutions 11 3.2.4.2 Subtask 4b – Implementation of Prototype 12 3.2.5 Task 5 – End-Product Testing 12 3.2.5.1 Subtask 5a – Test Planning 12 3.2.5.2 Subtask 5b – Test Development 12 3.2.5.3 Subtask 5c – Test Execution 12 3.2.5.4 Subtask 5d – Test Evaluation 13 3.2.5.5 Subtask 5e – Test Documentation 13 3.2.6 Task 6 – End-Product Documentation 13 3.2.7 Task 7 – End-Product Demonstration 13 3.2.7.1 Subtask 7a – Demonstration Planning 13 3.2.7.2 Subtask 7b – Faculty Advisor Demonstration 14 3.2.7.3 Subtask 7c – Company Demonstration 14 3.2.8 Task 8 – Project Reporting 14 3.2.8.1 Subtask 8a – Project Plan Development 14 3.2.8.2 Subtask 8b – Project Poster Development 14 3.2.8.3 Subtask 8c – End-Product Design Report Development 14 3.2.8.4 Subtask 8d – Project Final Report Development 15 3.2.8.5 Subtask 8e – Weekly Email Reporting 15

ii 4 Estimated Resources and Schedules 15 4.1 Estimated Resource Requirements 15 4.1.1 Personnel Effort Requirements 15 4.1.2 Other Resource Requirements 18 4.1.3 Financial Resource Requirements 19 4.2 Schedule 19 5 Closing Material 22 5.1 Project Team Information 22 5.1.1 Client Information 22 5.1.2 Faculty Advisors Information 22 5.1.3 May05-26 Team Members Information 22 5.2 Summary 23

iii 1.1 List of Figures Figure 1 – Steering Wheel Components 2 Figure 2 – Racing Game 3 Figure 3 – Optical Encoder 5 Figure 4 – Steering Wheel Pedals 7 Figure 5 – Personnel Efforts Requirement Estimate 17 Figure 6 – Other Resource Requirements Estimate (%) 18 Figure 7 – Gantt chart for Project Tasks 20 Figure 8 – Gantt chart for Deliverables 21

iv 1.2 List of Tables Table 1 – Personnel Effort Requirements Estimate 16 Table 2 – Other Resource Requirements Estimate 18 Table 3 – Financial Requirements Estimate 19

v 1.3 List of Definitions

The following terms are used throughout this report and may not be widely known or understood.

Assembly Language: Programming language one level above binary machine code.

C: Programming language used for many hardware systems

Breadboard: Structure used for the quick assembly/destruction of small circuits for the purpose of testing.

Hardware Interface Driver (HID): Software that converts hardware output into a standard from that can be used by computers

Integrated Circuit (IC): Small electrical single-function or multi-function device

Microcontroller: Device responsible for receiving and handling electrical signals from the various steering wheel devices

Optical Encoder: Small device used to detect rotational movement. Its resolution is determined by the number of ticks that it can detect through one full rotation

Printed Circuit Board (PCB): Structure that holds small electrical components and their respective connections

Potentiometer: Variable resistor. Potentiometers are commonly used in speaker devices to change the volume. SPICE: Software used primarily for circuit simulation

Universal Serial Bus (USB): Standard port that allows connection to external devices (such as digital cameras, scanners, and mice) to computers

vi 2 Introductory Material

This section will introduce the project and specifically define the problem statement. Topics discussed are the problem statement, operating environment, intended users and uses, assumptions and limitations, and the expected end product and deliverables.

1.4 Abstract Professional race car drivers and serious video game enthusiasts demand a higher level of precision from their video game steering wheel controllers. Thomas Enterprises wishes to create an inexpensive upgrade for their current video game controller products which will allow higher precision and control for their customers. Incorporating optical sensors and upgrading the USB interface PCB of the current products will allow a direct upgrade for Thomas’ current product line and will deliver the performance demanded by the most serious gamers. The higher resolution and sensitivity of the upgraded components will open Thomas’ products up to a wider market share and bolster their position as a leader in production of video game controllers.

1.5 Acknowledgement Special thanks go to Thomas Enterprises of Anamosa, Iowa. Thomas Enterprises, the client of this project, has provided the video game controller hardware and racing simulation software for the team to use in researching the team’s design. Appreciation is also expressed to Andrew Bice of Iowa State University’s Center for Industrial Research and Service. Mr. Bice designed the original USB interface PCB and will provide the team with the technical documentation generated during the original design. Faculty advisors Dr. Doug Jacobson and Dr. Jim Davis have also provided guidance and advice for this project. Gratitude is expressed for their efforts.

1.6 Problem Statement Thomas’ current products are capable of sensing 255 positions on the steering wheel and pedals and they also accept 16 pushbutton inputs. The output of the PCB connects to a personal computer through a USB cable. The desired upgrade would be a direct replacement for the current sensors and PCB. The ideal solution would be capable of sensing at least 1024 positions and retaining all 16 pushbutton inputs. The end-product should cost on the order of $30 - $50 but no more than $150.

1.7 Solution Approach The solution for this project requires choosing optical encoders that will replace the potentiometers that are currently being used to sense the position of the steering wheel and pedals. The encoders will need to have the desired resolution to provide the

1 precision control that is required for this application. The encoders should be capable of mounting in the same position as the current potentiometers. The current microcontroller senses the input from the wheel, pedals, and pushbuttons and sends output to the computer through a USB cable. The microcontroller will most likely need to be replaced by another microcontroller that is capable of accepting the higher resolution input and all the pushbutton functions. Computer code will need to be written in order to send instructions to the microcontroller. The code may be written in C or assembly language. The figure below illustrates the different components on the steering wheel that the team will be working with.

Potentiometer

Microcontroller

Figure 1 – Steering Wheel Components

1.8 Operating Environment The video game controllers are used with personal computers. In most instances the controllers will be used indoors, or in similar conditions where temperature, moisture, and other environmental factors will be controlled. The typical conditions for use are:  Temperature of approximately 70°F  Little to no wind  No rain or snow  Mostly dust-free conditions Thomas Enterprises does operate a built to scale race car simulator that is taken to local community events. The controller must operate in an outdoor environment under this circumstance, although the simulator would not be operated under adverse weather conditions. The product is relatively robust and strong mechanically such that it will last a long time under normal use. Even though it is durable and strong it is not intended to be dropped or thrown but could withstand a drop from approximately 2 - 3 feet. The steering wheel

2 assembly is attached to a desk or table for use by a bracket similar to a C-clamp. The pedals sit on the floor and are heavy so that they will stay in place when the pedals are pushed.

1.9 Intended Users The intended users of this product are serious video gamers, race car drivers, and others who would play racing games on a personal computer and demand a high quality product with high sensitivity from the controller input. The typical description of a person who fits into the category of the intended users is a male, age 12–30, with at least a high school education. Described above is the typical user, but many other people can use and enjoy the product. It could potentially be used by any male or female, ages 10 and up, with at least a junior high educational level. Nearly any person who desires to play racing or driving video games on a personal computer could use this product.

1.10 Intended Uses It is intended that a person would use this product in their home at a table or desk on video games that are played on a personal computer. The controller is interfaced to the computer via the standard hardware interface drivers (HIDs) that are currently being used. The most common games used with the controller are racing simulation games. Thomas Enterprises also has customers who are interested in controllers for other simulations, such as semi truck driving. It is assumed that this controller will not be used on video game consoles such as Sony PlayStation® or Nintendo GameCube®. It cannot be used to control any video game; it only controls games that accept input from the steering wheel device. The figure below shows a typical racing game that can make use of the steering wheel.

3 Figure 2 – Racing Game

1.11 Assumptions The team assumes the following statements in the design of the project solution.  The team may be able to modify the existing computer code so that the current microcontroller will be able to sense the wider range of input from the optical encoder. This would be the most cost effective solution.  If modifying the code is not enough to complete the upgrade then a new microcontroller will have to be chosen.  If a new microcontroller is required then it may not fit in the socket of the current PCB. Under this circumstance a new PCB would have to be designed.  All the original schematics, documentation, part numbers, computer code, and other relevant data from the design of the original PCB still exist and will be available for the team’s use.

1.12 Limitations The project solution must operate under the following limitations.  A replacement PCB should be of the same dimensions as the original so that it can be replaced in existing products.  Optical encoders should also be able to be replaced in the same location as the current potentiometers so that existing products can be easily upgraded.  Cost should be kept as low as possible, but it is more important to design a product that meets the desired functionality.  The PCB should have all the same connections, inputs, and outputs as the existing PCB.

1.13 Expected End-Product and Other Deliverables The end-product will include.  Optical encoders that will be used to provide much greater input sensitivity. The optical encoders will be direct replacements for the analog potentiometers that are currently being used.  A PCB which receives input from the encoders and pushbuttons and sends output to the computer through a USB cable. The USB interface PCB should be able to discern at least 1024 positions of the steering wheel and foot pedals. The PCB should be of the same external dimensions of the original board so that it may be directly replaced in existing products. The minimum required quality of the end-product is at least of prototype quality, although the higher quality and reliability that the team has time to design and test, the better. If a suitable outside vendor can be found to manufacture the PCB’s in high volume for Thomas Enterprises, then it should be fairly simple to implement the circuit design in a way that is robust enough for high volume manufacturing.

4 Thomas Enterprises may also wish to have technical documentation, specifications, and instructions that will fully explain the operation of the encoders and USB interface PCB. They have not asked for this to be delivered, but it may be possible to deliver these items so they can provide a higher level of service on their products.

3 Proposed Approach and Statement of Work

The proposed approach to the design of the end-product and statement of work is discussed in this section.

1.14 Proposed Approach The following sub-section addresses the team’s proposed approach to the problem statement. Discussed topics are project requirements, constraints, and management procedures.

1.14.1 Functional requirements The project solution must meet the following functional requirements.  Longevity of the product: The new steering wheel controller design with optical encoders should last longer than the potentiometer design and require little or no replacement.  Higher resolution: The optical encoders (similar to the one shown at right) should recognize 1024 positions for the steering wheel. This will, in turn, provide a more realistic gaming experience to the end user.  16 function buttons: The controller should maintain the 16 button layout that the current PCB has. Figure 3 – Optical Encoder

1.14.2 Constraints considerations The project solution must adhere to the following constraints:  Dimensions: The dimensions of the finished PCB should be no larger than the current design of 13.5 cm x 6 cm.  Wear and tear: The product should be sturdy and be able to handle racing simulations, which can include long usage periods for the steering wheel and pedals. With the replacement optical encoders, it will no longer be necessary to maintain the internal workings of the controller.

5 1.14.3 Technology considerations The project solution will address the following technology considerations.  USB connectivity: The device will use USB to connect to the computer, using the same HIDs that the current PCB uses. There is no reason to migrate to a different type of connection, when there are already working drivers.  Optical encoders: In one revolution of turning, the wheel should have 1024 positions. Optical encoders will also be installed on the pedals. The optical encoders will replace the potentiometers on the current PCB.

1.14.4 Technical approach The initial setup will include the evaluation of the current PCB and its limitations. These limitations will be documented and later compared with the end-product. The existing programming code for the USB driver will also be examined to determine if any changes will be necessary after the implementation of the optical encoders. The PCB design will start with the research of the different optical encoders available. If necessary, SPICE simulations may be performed to determine if the output is desirable. Once an appropriate encoder is chosen, the physical implementation can begin. The construction of the new PCB can be in done in a few stages. The first stage will include a schematic for the new layout with the optical encoders. This can also be done in a SPICE simulation. The second stage will be the actual assembly of the parts onto a breadboard. Some adjustments will be made to compensate for the real specifications for each part, instead of having ideal outputs and specifications. The third stage will be the final implementation of the PCB which will represent the prototype. After a prototype is built, adjustments can be made to the current code for the encoder and other data output to interface with the current HIDs properly.

1.14.5 Testing requirements The finished product should function with the provided simulation racing software. Each of the buttons should be programmable within the game. If any major changes were made to the USB driver, the connection should be tested across multiple platforms to ensure compatibility with most modern computers. Initial lab testing will be carried out by the team members. Once the controller is operational, testing will be performed by a gaming enthusiast or one that is interested in racing simulation. Upon completion of these two testing periods, the final test will demonstrate the functionality to the company, Thomas Enterprises. The original steering wheel limitations that were earlier noted should now be compared to the results of the optically encoded steering wheel.

1.14.6 Security considerations There are few security considerations with the design of the steering wheel. During the project, the company, Thomas Enterprises, has given us a working steering wheel and software. As it is required to work with the source code for the software and drivers, and

6 also work with the existing PCB, there is an implicit understanding that the team will not attempt to market or sell the product to a competitor. After the project has been completed, there lie the same considerations as before. The source code will only be in the company’s possession. As far as the physical product, there is no safeguard against an end user to open up the device and examine the circuitry.

1.14.7 Safety considerations In dealing with any electronics, there is always an inherent safety consideration. One must apply caution when handling electronics, including voltage connections, proper part placement, and keeping the PCB free of any foreign elements that may damage the electronic parts. Use of the steering wheel is also a safety consideration. Proper care should be exercised when lifting or transporting the steering wheel and pedals. The controller and pedals are quite heavy may cause injury if it is dropped on a person. The pedals are illustrated in the figure to the right. Figure 4 – Steering Wheel Pedals

1.14.8 Intellectual property and commercialization considerations As described in the security considerations, the source code is the major element that will have any intellectual property considerations. If the company, Thomas Enterprises, feels that the software is too important to release the source code, arrangements will be made with the software designer to work with the team. The modifications to the PCB will be performed under the assumption that any changes will still be property of Thomas Enterprises. The team will not attempt to sell, share, or otherwise infringe on any copyrighted material of the PCB or software. It is understood that Thomas Enterprises will continue to commercialize this product with the modified design.

1.14.9 Possible risks and risk management Most of the work will take place in the senior design lab, all PCB design will remain in the senior design lab, and any programming will be done in the lab. Precautions must be taken to insure that design work (hardware and software) remains protected from theft or destruction. Components and materials will be stored in the senior design lab in a secure storage locker. If for whatever reason the senior design lab becomes unavailable, the team should be able to continue work in many of the other labs on campus, or possibly on Thomas Enterprises company property. In the event of a team member leaving, it will be in good faith that that team member will not exploit any of the previous work. Though we will have documentation of every team member’s progress, there will be a chance that some work will not be recovered. Having

7 Mr. Bice as a resource (Mr. Bice is the original PCB designer), successful project completion should remain feasible.

1.14.10 Project Proposed Milestones and Evaluation Criteria In this project, milestones and evaluation criterion are used to determine the completion of the project. After all milestones are completed, the project will be evaluated with to determine whether the result is satisfactory.

1.14.10.1 Proposed Milestones These milestones are set to note the significant accomplishments in the project.  Device functionality  Software functionality  Successful operation with software and computer  Comprehensive documentation for product  Satisfies company’s expectations Each team member will have a primary role, with contributions noted. Each team member will have approximately the same workload; however, the team will be evaluated as a whole.

1.14.10.2 Evaluation Criterion The project will be evaluated on a numerical scale from 0 to 100, based on the following criterion. All of these considerations are equally weighted.  Does the device work with the specified platforms (computers that are USB capable)?  Was the project completed within budget of $150?  Do the new optical encoders work with the software?  Do the optical encoders exceed the previous design’s limitation?  Is the documentation easy to understand?  Is the company satisfied with the improvements and results?

1.14.11 Project tracking procedures The team will implement a project tracking system on Microsoft Project, or similar program. It will be the responsibility of each team member to log daily activity into the program, including expenditures, hours worked, and what was done on the project.

1.15 Statement of Work This sub-section will outline the work of the project. The procedure and results expected at each stage of our project will be listed. It is in chronological order, except for Task 8 which is concurrent with all other tasks.

8 1.15.1 Task 1 – Problem Definition  Task Objective: The team shall have an understanding of the specifications, users and constraints of the product.  Task Approach: The team will collect the company's specifications and requirements. The team will also identify their targeted group for the product, which would be the product’s end-users. The constraints will be learned, as well.  Task Expected Results: A list of specifications and constraints, along with an identified target market for the product.

1.15.1.1 Subtask 1a – Problem Definition Completion  Task Objective: The team shall know the specifications of the product to be delivered.  Task Approach: The team will contact the company and get their specifications for the end-product. The team will clarify any gaps in the specifications with the help of the company representative.  Task Expected Results: A list of specifications that the product must follow.

1.15.1.2 Subtask 1b – End-User Identification  Task Objective: Learn the market segment for which the end-product is targeted.  Task Approach: Contact the company to find out to which market segment they intend to market the end-product, and what information they have on this group. The team will work with the representative to determine how this information should influence our design.  Task Expected Results: The demographic of the target market, as well as any special considerations this group must be given.

1.15.1.3 Subtask 1c – Constraint Identification  Task Objective: Identify the constraints on the final product, and the specifications of the parts of the product the team is to work with and not change.  Task Approach: Communicate with the company to get their restrictions on the end-product, such as cost and power requirements. The team will also obtain their documentation of the current product and identify which parts are not to be changed.  Task Expected Results: A list of constraints that the final product must fit within and documentation of the current product.

1.15.2 Task 2 – Technology Consideration and Selection  Task Objective: Choose the components to be used for the team’s product.  Task Approach: The team shall identify the performance and form requirements of the components to be used in the team’s product. The team shall locate components which meet these criteria. The team shall then select from this set which components to use in the end-product.

9  Task Expected Results: A selection of the optimal components to use in the team’s design.

1.15.2.1 Subtask 2a – Identification of Selection Criteria  Task Objective: Determine the criteria to judge possible components of the product.  Task Approach: The team will identify the required specifications for each component, using the problem definition. Performance characteristics to optimize will also be identified. The components where space requirements are an issue will be noted and the desired form for them will be decided upon as well.  Task Expected Results: A list of requirements and specifications to optimize for each component.

1.15.2.2 Subtask 2b – Technology Research  Task Objective: Gather information on available components which may meet the product criteria.  Task Approach: The team will research components' specifications online or in catalogs. Any that meet estimated criteria will be recorded and distributed among the group for later consideration.  Task Expected Results: Details on the various components which may meet the product needs.

1.15.2.3 Subtask 2c – Technology Selection  Task Objective: A set of components which meets the team’s requirements and is optimal in other criteria is chosen.  Task Approach: The components identified in subtask 2b will be compared to each other using the team’s criteria for selection. Appropriate weighing of each criterion will be applied if compromises are needed. The optimal component will be chosen from this comparison.  Task Expected Results: A selection of the optimal components for use in the end- product.

1.15.3 Task 3 – End-Product Design  Task Objective: Produce a final design for the end-product.  Task Approach: The requirements from Task 1 and the team’s component selection from Task 2 will be used as the tools for the final design. The controller board layout and components will be finalized. The specifications for the controller IC's software will be developed. The team will design fittings for the optical encoder if they are needed.  Task Expected Results: A completed design for the end-product.

10 1.15.3.1 Subtask 3a – Identification of Design Requirements  Task Objective: Identify all functional and performance requirements of the end- product.  Task Approach: Using the requirements from Task 1, the team will produce a final listing of criteria and optimizations to be made. Each criterion will be prioritized with respect to its importance to the final product.  Task Expected Results: A comprehensive set of design requirements will be produced.

1.15.3.2 Subtask 3b – Design Process  Task Objective: Produce a detailed design for the end-product.  Task Approach: The requirements produced in Subtask 3a will be the guidelines for the final design. The design sections will be equally divided among the team along the lines of expertise, or preference, if some team members are equally suited for a section. The individual sections will be combined, checked, and finalized as a group to ensure correctness and quality.  Task Expected Results: A completed, detailed design for the end-product.

1.15.3.3 Subtask 3c – Documentation of Design  Task Objective: Accurately document the design produced in Subtask 3b.  Task Approach: The design will be documented fully, using the notes of each group member on their section along with group work on the overall design and synthesis of the sections. The documentation will be submitted to the faculty advisors and the company contact for approval. Any modifications requested will be incorporated into the final documentation.  Task Expected Results: Design documentation which has been approved by the faculty advisors and company contact.

1.15.4 Task 4 – End-Product Prototype Implementation  Task Objective: Produce a working prototype of the final product.  Task Approach: The team will identify substitutions and other changes that must be made for the prototype different the final version. Then the design produced in Task 3 will be used to construct the prototype implementation. The prototype will be made suitable for demonstrations and testing.  Task Expected Results: A working, demonstrable prototype of the end-product.

1.15.4.1 Subtask 4a – Identification of Prototype Limitations and Substitutions  Task Objective: Identify any substitutions or restrictions that must be made to the prototype due to its pre-production status.  Task Approach: Any components that must be substituted into the prototype which would not be in finished product will be decided upon. The team will also determine the choice and implementation of the replacement parts, with near- identical functionality being the goal.

11  Task Expected Results: A list of components that must be substituted in the prototype.

1.15.4.2 Subtask 4b – Implementation of Prototype  Task Objective: Construct a working prototype of the end-product.  Task Approach: The team will construct a prototype product using the substitutions chosen and designed in Subtask 4a. Functionality for testing is the main concern of the prototype and its primary purpose. However, since the prototype will also be used for demonstrations form and style will not be neglected.  Task Expected Results: A working prototype of the end-product.

1.15.5 Task 5 – End-Product Testing  Task Objective: Ensure that the product functions as it was designed.  Task Approach: A set of tests to comprehensively ensure the function of the product will be designed by the team. The team will then perform these tests and evaluate the results. Any flaws found in the product will be documented, fixed and re-tested.  Task Expected Results: The function of the product is confirmed to match the requirements and design.

1.15.5.1 Subtask 5a – Test Planning  Task Objective: Plan a set of tests to ensure the functioning of the product.  Task Approach: The team will design a set of tests that will cover each of the functional requirements of the product. Test cases will be made with input sets and expected results. The team will determine if exhaustive testing is necessary or if another strategy is possible.  Task Expected Results: A plan for a set of tests.

1.15.5.2 Subtask 5b – Test Development  Task Objective: Establish a test set-up for evaluating the prototype.  Task Approach: Following the plan developed in Subtask 5a, the team will choose suitable test equipment and develop the test cases for the prototype. The team will then code the test cases for the testing program.  Task Expected Results: A test set-up that will accurately evaluate the performance of the prototype.

1.15.5.3 Subtask 5c – Test Execution  Task Objective: Perform tests on the prototype to gather data about its performance.  Task Approach: The team will run the tests written in Subtask 5b on the controller to verify its functionality. In addition to the team's testing, the prototype will also be tested for in-game use by a member of the intended audience.

12  Task Expected Results: Comprehensive data on the prototype's function.

1.15.5.4 Subtask 5d – Test Evaluation  Task Objective: Evaluate the data from Subtask 5c about the prototype's function.  Task Approach: The team shall check the data received from Subtask 5c against the expected results. The team will also evaluate the feedback from the in- game testing and determine if it meets playability standards.  Task Expected Results: The prototype is evaluated and proper function is verified.

1.15.5.5 Subtask 5e – Test Documentation  Task Objective: Distribute and get approval of the testing results.  Task Approach: The results from Subtask 5d will be sent to the faculty advisors and to the company contact for approval. Any additional testing requested will be performed. If necessary, the documentation of results will be resubmitted.  Task Expected Results: Approval of the testing results.

1.15.6 Task 6 – End-Product Documentation  Task Objective: Produce documentation for use by the company in support of the product and in later development of the technology.  Task Approach: The team will collect the detailed design plans as well as the testing set-up, methodology and results. The team members will receive copies and deliver others to the company contact and faculty advisor.  Task Expected Results: The full documentation is delivered to the company.

1.15.7 Task 7 – End-Product Demonstration  Task Objective: The product is shown and demonstrated to the interested groups.  Task Approach: A suitable demonstration of the steering wheel's design and use will be made by the team. The presentation will be given to the faculty advisors and later, to the company representatives.  Task Expected Results: The product is displayed and explained to the advisors and company.

1.15.7.1 Subtask 7a – Demonstration Planning  Task Objective: An interesting, informative presentation on the product will be written.  Task Approach: The team will produce a multimedia presentation on the product developments, verification, and design. The demonstration will clearly show the product’s proper functionality, major design features, and any particular hurdles the team had to overcome.  Task Expected Results: A presentation that can be given to the company and advisors.

13 1.15.7.2 Subtask 7b – Faculty Advisor Demonstration  Task Objective: Demonstrate the product to the team’s faculty advisors.  Task Approach: The team will deliver the presentation written in Subtask 7a to the team’s faculty advisors.  Task Expected Results: Final approval from the advisors.

1.15.7.3 Subtask 7c – Company Demonstration  Task Objective: Demonstrate the product to the company.  Task Approach: The team will deliver the presentation written in Subtask 7a to the company representatives.  Task Expected Results: Final approval from the company.

1.15.8 Task 8 – Project Reporting  Task Objective: Keep interested parties informed on the progress of the team’s work.  Task Approach: The team will develop a project plan describing the intended course of the work. The team will produce a poster highlighting project developments. The team will write an end-product design report and a project final report. The team will also write weekly status emails.  Task Expected Results: A project plan, a project poster, an end-product design report, a final report, and weekly status emails.

1.15.8.1 Subtask 8a – Project Plan Development  Task Objective: Write a comprehensive plan for the time, resources, and steps of the project.  Task Approach: The team will divide the planning and report into sections to be compiled into one report. The final details shall be worked out as a group. The group will later revise the plan in accordance with feedback received.  Task Expected Results: A comprehensive plan for the execution of the project.

1.15.8.2 Subtask 8b – Project Poster Development  Task Objective: Produce an interesting poster highlighting the development of the project.  Task Approach: The team will arrange graphics a summary of key areas of the project, expected effort contributions, and project timeline on a poster for display.  Task Expected Results: A visually appealing poster explaining the basics of the project.

1.15.8.3 Subtask 8c – End-Product Design Report Development  Task Objective: Write a report on the design of the end-product.

14  Task Approach: Working from the design documents from Subtask 3c, the team will write a report on the end-product. The report will include the design and component choice information written earlier.  Task Expected Results: A report detailing the end-product.

1.15.8.4 Subtask 8d – Project Final Report Development  Task Objective: Write a report on the final status of the project.  Task Approach: The team will describe the final status of the project along with detailing the work and budget that has been involved in the development. The report will contain design, implementation and testing information. The work will be divided similar to the project plan.  Task Expected Results: A report describing the final status of the project.

1.15.8.5 Subtask 8e – Weekly Email Reporting  Task Objective: Keep advisors and the company contact up to date on the progress of the project.  Task Approach: The team will compose a weekly email on the developments and issues faced during the week. This email will be sent to the project mailing list which includes the company contact and faculty advisors.  Task Expected Results: Weekly status emails.

4 Estimated Resources and Schedules

The estimated resource requirements and schedules are discussed in this section. This section will be a prime indicator of whether or not the project has been a success upon the completion of the project.

1.16 Estimated Resource Requirements The following sub-section covers the estimated time and money required for the project to be completed successfully.

1.16.1 Personnel Effort Requirements The team members have estimated the required effort needed to complete the project tasks successfully. The following table displays this information in terms of the number of hours of work expected to complete each project task successfully in addition to the total time expected to complete the entire project successfully. Figure 5 displays the information graphically.

15 Table 1 – Personnel Effort Requirements Estimate

t e a r p g e y n t n d g i i i o n t t s s g o s o i n e n r t e i i n o n t n D P T n r o o i

i i C n o f t t t t t t i o t

t o e c c c c c i a p a y t t a t u u u u u e g r D c n n t

d d d d d o R l e e e s l o o o o o m t o r r r r r n e m m e c n o s l P P P P P l S e u - - - - - e h l

b j a c m d d d d d c p t d o o o e r n n n n n r e o n m

Team Member P T a E E I E E D E D P T Dahlke, Samuel 8 15 60 50 25 15 20 20 213 Fecteau, Peter 10 20 40 40 20 30 20 20 200 Pates, Daniel 8 20 60 40 30 50 10 20 238 Subido, Lorenzo 10 15 50 40 15 40 10 20 200 Combined Effort 36 70 210 170 90 135 60 80 851

16 Figure 5 – Personnel Efforts Requirement Estimate Project Reporting Dahlke, Samuel Fecteau, Peter Pates, Daniel Subido, Lorenzo End-Product Demonstration

End-Product Documentation

End-Product Testing

End-Product Prototype Implementation

End-Product Design

Technology Consideration and Selection

Problem Definition

0 50 100 150 200 250

17 1.16.2 Other Resource Requirements The team has estimated the cost of the required resources needed in order to complete the project successfully. The following table displays the estimated required resources and their respective costs. Figure 6 displays the information as percentages of the total projected cost.

Table 2 – Other Resource Requirements Estimate Materials: Cost Microprocessor $10.00 Optical Encoder $50.00 (Donated) Miscellaneous Parts $10.00

Miscellaneous Resources: Poster $50.00 Total $120.00

5% Microprocessor Optical Encoder Miscellaneous Parts Poster

64% 5%

Figure 6 – Other Resource Requirements Estimate (%)

18 1.16.3 Financial Resource Requirements The team has estimated the cost of labor for each team member over the course of the project. Although the team members will be working without pay, for the purposes of the project, adding labor costs adds context to the potential expenses of this project in a real-world sense. The following table displays the estimated cost of the project with and without labor costs.

Table 3 – Financial Requirements Estimate Materials: Without Labor With Labor Microprocessor $10.00 $10.00 Optical Encoder $50.00 $50.00 Miscellaneous Parts $10.00 $10.00 Subtotal $70.00 $70.00 Miscellaneous Resources: Poster $50.00 $50.00

Labor at $10.50 per hour:

Dahlke, Samuel $2,236.50 Fecteau, Peter $2,100.00 Pates, Daniel $2,499.00 Subido, Lorenzo $2,100.00 Subtotal $8,935.50 Total $120.00 $9,055.50

1.17 Schedule The following sub-section contains estimated schedules of work proposed by the team and course advisors. The information is given in the two following Gantt charts which display the estimated time planned for each of the tasks outlined in the schedule of work and the set of deliverables expected from the team over the course of the project.

19 September October November December January February March April Task Name ID 29 5 12 19 26 3 10 17 24 31 7 14 21 28 5 12 19 26 2 9 16 23 30 6 13 20 27 6 13 20 27 3 10 17 24 1 1 Problem Definition 2 Problem Definition Completion 3 End-User Identification 4 Constraint Identification 5 Technology Consideration and Selection 6 Identification of Selection Criteria 7 Technology Research 8 Technology Selection 9 End-Product Design 10 Identification of Design Requirements 11 Design Process 12 Documentation of Design 13 End-Product Prototype Implementation 14 Identification of Prototype Limitations and Substitutions 15 Implementation of Prototype 16 End-Product Testing 17 Test Planning 18 Test Development 19 Test Execution 20 Test Evaluation 21 Test Documentation 22 End-Product Documentation 23 End-Product Demonstration 24 Demonstration Planning 25 Faculty Advisor Demonstration 26 Company Demonstration 27 Project Reporting 28 Project Plan Development 29 Project Poster Development 30 End-Product Design Report Development 31 Project Final Report Development 32 Weekly Email Reporting

Task Task Progress

SubTask SubTask Progress

Figure 7 – Gantt chart for Project Tasks

20 September October November December January February March April ID Task Name 29 5 12 19 26 3 10 17 24 31 7 14 21 28 5 12 19 26 2 9 16 23 30 6 13 20 27 6 13 20 27 3 10 17 24 1 1 Project Deliverables 2 Unbound Project Plan 3 Bound Project Plan 4 Project Poster 5 Unbound Design Report 6 Bound Design Report 7 Unbound Final Report 8 Demonstration 9 Bound Final Report 10 Weekly Email Reports

Task Task Progress

SubTask SubTask Progress Figure 8 – Gantt chart for Deliverables

21 5 Closing Material

Project team information is given in this section, followed by a brief summary of the project.

1.18 Project Team Information This sub-section includes client, faculty advisor, and team member contact information.

1.18.1 Client Information Thomas Enterprises David Thomas Sr., President David Thomas Jr., Vice President 13859 Buffalo Road Anamosa, IA 52205 319-462-3327 [email protected]

1.18.2 Faculty Advisors Information Dr. James Davis Dr. Douglas Jacobson 2550 Beardshear 2419 Coover Ames, IA 50011 Ames, IA 50011-3060 515-294-0323 515-294-8307 [email protected] [email protected]

1.18.3 May05-26 Team Members Information Samuel Dahlke, CprE Peter Fecteau, CprE 7312 Frederiksen Court 6326 Frederiksen Court Ames, IA 50010 Ames, IA 50010 515-572-7972 515-572-7844 [email protected] [email protected]

Daniel Pates, EE Lorenzo Subido, EE 205 South 5th Street, apt. 907 2355 Wallace Ames, IA 50010 Ames, IA 50013 515-450-4380 515-572-2090 [email protected] [email protected]

22 1.19 Summary Thomas Enterprises, a producer of top-of-the-line gaming and simulation steering wheel controllers, needs to keep their product line competitive. To this end, they wish to use optical encoders to increase the sensitivity in their controllers. The end-product of this project will provide the upgrade Thomas Enterprises wishes to incorporate into their product line. The end-product will include an optical encoder and a new microprocessor that will interface properly with current hardware. Ease of implementation will be a major factor in the end-product design. It will allow Thomas Enterprise to update controller production and existing controllers at low cost.