Project Proposal and Feasibility Study - · PDF fileCalvin College Engineering Department Senior Design Project Project Proposal and Feasibility Study Team 3 Arnold Aquino, Daniel

Calvin College Engineering Department

Senior Design Project

Project Proposal and Feasibility Study

Team 3

Arnold Aquino, Daniel Bosscher, Walter Schnoor, Daniel Ziegler

Engineering 339

12 December 2011

Team 3 Sim Escape

12 December 2011 Project Proposal and Feasibility Study

Executive Summary

The proposed senior design project is a head mounted display (HMD) simulation system that immerses a

user in a virtual environment. The purpose of this design is to give an accurate representation of

situations that are not feasible, safe, or otherwise realizable. This product can then be used for training,

designing, and learning in a safe and productive manner.

The goal of the project of creating an immersive environment will be achieved through designing as

natural a human-machine interface as possible. This interface will include a stereoscopic 3 dimensional

display array to be mounted in front of the user’s eyes to give a realistic view of the environment and a

head motion tracking system to allow the user to control the view with natural motion.

The proposed design of this system was determined to be technically feasible as a two semester academic

project. The design success is defined by meeting requirements for system latency, picture quality, weight,

and cost.

Design projections for full scale production were estimated and determined to be a financially feasible

model for a business with a 20% growth in the first three years and an internal rate of return of 48% after

those three years.

Team 3 Sim Escape i


Table of Contents 1 Project Introduction .............................................................................................................................. 1

1.1 Project Definition and Motivation ................................................................................................ 1 1.2 Acronym Definitions .................................................................................................................... 1 1.3 Course Overview .......................................................................................................................... 2 1.4 Team Information .......................................................................................................................... 3

1.4.1 Arnold Aquino ...................................................................................................................... 3 1.4.2 Dan Bosscher ........................................................................................................................ 3 1.4.3 Walter Schnoor ...................................................................................................................... 3 1.4.4 Dan Ziegler ........................................................................................................................... 4

2 System Architecture ............................................................................................................................. 4

2.1 Overall System .............................................................................................................................. 4 2.2 Head Tracker ................................................................................................................................. 5 2.3 Software ........................................................................................................................................ 5 2.4 Display System ............................................................................................................................. 5

3 Requirements ........................................................................................................................................ 5

3.1 Functional Requirements .............................................................................................................. 6 3.2 Electrical Requirements ................................................................................................................ 6

3.2.1 Head Tracker ......................................................................................................................... 6 3.2.2 Software ................................................................................................................................ 6 3.2.3 Display System ..................................................................................................................... 7

3.3 Physical Requirements .................................................................................................................. 7

3.3.1 Product Weight ...................................................................................................................... 7 3.3.2 Product Shape ....................................................................................................................... 8 3.3.3 Product Materials .................................................................................................................. 8

3.4 Power Requirements ..................................................................................................................... 8 3.5 Safety Requirements ..................................................................................................................... 9

3.5.1 Electrical Safety .................................................................................................................... 9 3.5.2 Physical Safety and Health Concerns ................................................................................... 9

3.6 Design Norms ............................................................................................................................... 9

3.6.1 Designing for Humility ....................................................................................................... 10 3.6.2 Designing for Trust ............................................................................................................. 10 3.6.3 Designing a Product of Integrity ......................................................................................... 10 3.6.4 Designing as Stewards ........................................................................................................ 10

4 Electrical System Specifications ........................................................................................................ 10

4.1 Head Tracker ............................................................................................................................... 11

4.1.1 Sensors ................................................................................................................................ 12 4.1.2 Data Acquisition .................................................................................................................. 17 4.1.3 System Integration .............................................................................................................. 18 4.1.4 Testing ................................................................................................................................. 18

4.2 Software ...................................................................................................................................... 19

4.2.1 Input Interface ..................................................................................................................... 20

Team 3 Sim Escape ii


4.2.2 Input Mapping ..................................................................................................................... 21 4.2.3 Virtual Environment Development and Simulation ............................................................ 22

4.3 Display System ........................................................................................................................... 25

4.3.1 3D Display Method ............................................................................................................. 25 4.3.2 Video Processing Platform .................................................................................................. 27 4.3.3 Video Input Format ............................................................................................................. 33 4.3.4 Video Buffers ...................................................................................................................... 38 4.3.5 Video Output Format (to the LCDs) ................................................................................... 41

5 Physical System Specifications .......................................................................................................... 43

5.1 Helmet ......................................................................................................................................... 43 5.2 System Interface Module (SIM) Enclosure................................................................................. 43 5.3 Wiring and Interconnection ......................................................................................................... 43 5.4 Optics .......................................................................................................................................... 43

6 System Integration Testing ................................................................................................................. 44

6.1 Video Delay Testing .................................................................................................................... 44 6.2 Motion Sensitivity Testing .......................................................................................................... 44 6.3 Power Consumption Testing ....................................................................................................... 44

7 Business Plan ..................................................................................................................................... 44

7.1 Vision and Mission Statement ..................................................................................................... 44 7.2 Industry Profile and Overview .................................................................................................... 45

7.2.1 Major Customer Groups ...................................................................................................... 45 7.2.2 Regulations and Restrictions ............................................................................................... 46 7.2.3 Significant Trends ............................................................................................................... 46 7.2.4 Growth Rate ........................................................................................................................ 46 7.2.5 Barriers to Entry .................................................................................................................. 47 7.2.6 Key Success Factors in Industry ......................................................................................... 47 7.2.7 Outlook for the Future ......................................................................................................... 47

7.3 Business Strategy ........................................................................................................................ 47

7.3.1 Company Goals and Objectives .......................................................................................... 47 7.3.2 SWOT Analysis ................................................................................................................... 47 7.3.3 Competitive Strategy........................................................................................................... 48

7.4 Marketing Strategy ...................................................................................................................... 48

7.4.1 Target Market ...................................................................................................................... 49 7.4.2 Customers' Motivation to Buy ............................................................................................ 49 7.4.3 Market Size and Trends ....................................................................................................... 49 7.4.4 Advertising and promotion ................................................................................................. 49 7.4.5 Promotion Costs .................................................................................................................. 50 7.4.6 Pricing ................................................................................................................................. 50 7.4.7 Distribution Strategy ........................................................................................................... 50

7.5 Competitor Analysis .................................................................................................................... 51

7.5.1 Existing Competitors........................................................................................................... 51 7.5.2 Potential Competitors .......................................................................................................... 52

7.6 Financial Forecasts ...................................................................................................................... 53

7.6.1 Financial Forecast Description ............................................................................................ 53

Team 3 Sim Escape iii


7.6.2 Key Assumptions ................................................................................................................ 53 7.6.3 Financial Statements ........................................................................................................... 54 7.6.4 Break-Even Analysis ........................................................................................................... 54 7.6.5 Ratio Analysis ..................................................................................................................... 55

7.7 Loan or Investment Proposal ...................................................................................................... 55

7.7.1 Amount Requested .............................................................................................................. 55 7.7.2 Purpose of Uses of Funds .................................................................................................... 55 7.7.3 Repayment Schedule ........................................................................................................... 55 7.7.4 Timetable for implementing plan and launching the business ............................................ 55

8 Project Management ........................................................................................................................... 56

8.1 Team Organization ...................................................................................................................... 56

8.1.1 Division of Work ................................................................................................................. 56 8.1.2 Team Advisors and Support ................................................................................................ 56 8.1.3 Team Meetings .................................................................................................................... 56 8.1.4 Storing Files ........................................................................................................................ 57

8.2 Schedule ...................................................................................................................................... 57

8.2.1 Schedule Management ........................................................................................................ 57 8.2.2 Critical Path ........................................................................................................................ 57 8.2.3 Current Progress and Feasibility ......................................................................................... 58

8.3 Budget ......................................................................................................................................... 58 8.4 Method of Approach ................................................................................................................... 58

9 Conclusions ........................................................................................................................................ 59

9.1 Current Progress .......................................................................................................................... 59

9.1.1 Prototypes ........................................................................................................................... 59 9.1.2 Experiments ........................................................................................................................ 59 9.1.3 Setbacks .............................................................................................................................. 60

9.2 Remaining High Risk Obstacles ................................................................................................. 60

9.2.1 PCB Design ......................................................................................................................... 60 9.2.2 Lenses and Lens Mounting ................................................................................................. 60

10 Credits and Acknowledgements ......................................................................................................... 61 11 References .......................................................................................................................................... 62 12 Appendices ............................................................................................................................................ I

12.1 Appendix A – Angular Velocity Test Data ..................................................................................... I 12.2 Appendix B - Texas Instruments TMS320C647x Block Diagram ............................................... II 12.3 Appendix C – Projected Financials ............................................................................................. III 12.4 Appendix D – Project Prototype Budget ..................................................................................... VI 12.5 Appendix E – Team Work Breakdown Schedule ...................................................................... VII

Team 3 Sim Escape iv


List of Figures

Figure 1. Photo of Team 3 (Arnold Aquino, Dan Ziegler, Walter Schnoor, Dan Bosscher) ......................... 3 Figure 2. High Level System Interconnection .............................................................................................. 5 Figure 3. System Interface Module Block Diagram ................................................................................... 11 Figure 4. Head Tracker Block Diagram ...................................................................................................... 11 Figure 5. Software Architecture Block Diagram......................................................................................... 19 Figure 6. Display System Block Diagram .................................................................................................. 25 Figure 7. 16-Bit and 24-Bit RGB Color Resolutions .................................................................................. 37

List of Tables

Table 1. Meanings of Acronyms ................................................................................................................... 1 Table 2. Head Tracker Technology Alternatives ......................................................................................... 12 Table 3. Accelerometer Alternatives ........................................................................................................... 14 Table 4. Gyroscope Alternatives ................................................................................................................. 14 Table 5. Accelerometer Decision Matrix .................................................................................................... 16 Table 6. Gyroscope Decision Matrix .......................................................................................................... 17 Table 7. Data Acquisition Alternatives ....................................................................................................... 17 Table 8 Virtual Environment Software Decision Matrix ............................................................................ 23 Table 9. Video Processing Alternatives ....................................................................................................... 27 Table 10. FPGA Alternatives ...................................................................................................................... 30 Table 11. Proposed FPGA IO Pins (Minimum) .......................................................................................... 31 Table 12. Video Processor Test Matrix ....................................................................................................... 32 Table 13. Video Input Format Alternatives ................................................................................................. 34 Table 14. 16-Bit Color Format .................................................................................................................... 37 Table 15. Input Format Test Matrix ............................................................................................................ 38 Table 16. Frame Buffer Alternatives ........................................................................................................... 39 Table 17. Video Buffer Memory Test Matrix .............................................................................................. 41 Table 18. Output Video Test Matrix ............................................................................................................ 42 Table 19. Comparison of Competitor Product Functionality ...................................................................... 51 Table 20. Project Management Critical Paths ............................................................................................. 57

Team 3 Sim Escape Page 1 of 62


1 Project Introduction

1.1 Project Definition and Motivation

The primary goal of the team’s project is to design a simulation helmet that will allow the user to

visualize a computer generated virtual environment in three dimensions. In addition to being a 3D

visualization tool, the helmet will track movements of the user’s head. This will allow the user to look

around the virtual environment simply by turning their head.

The main reason for this project is the evolution of the human machine interface. A human machine

interface (HMI) is the means by which people interact with a technology. In 1946, ENIAC, the first

general-purpose computer, interacted with its users by means of a punched card. Since then, HMI

solutions have progressed to give us the keyboard and mouse, the handheld controller, and the touch

screen. In the past decade, these technologies have all been designed to answer this question: how do we

make interfacing to a machine feel as natural as possible? The more natural a HMI feels to the user, the

more likely the user is to both use the technology and benefit from the technology.

A natural feeling may not sound necessary for a task such as word processing. However, computers are

being used to solve much more complex problems such as flight training simulations, advanced robotic

surgery, and architectural modeling. These unique applications pose a challenge to the conventional HMI.

For these applications, it would be quite beneficial for the user to be able to become more immersed in the

interaction, from both an input and an output perspective. Advanced simulations are best seen rendered in

three dimensions. This is how the eye naturally perceives objects in space. In addition, when a person

wishes to see what is to their left or right, they look to the left or right. This sounds trivial, but computers

currently offer no ability to change what the user is seeing on a screen simply by turning their head. The

ability to visualize an environment in three dimensions and to look through this environment by simply

turning one’s head is something that would lend itself to making a simulation more immersive and

realistic for the user.

1.2 Acronym Definitions

Below in Table 1 is a list of acronyms that apply to the project. This table is for reference and the reader’s

convenience.

Table 1. Meanings of Acronyms

Acronym Meaning

3D Three Dimensional

AV Audio-Visual

BGA Ball Grid Array

CPU Central Processing Unit

DAQ Data Acquisition

DMA Dynamic Memory Access

DSP Digital Signal Processor

DVI Digital Video Interface

FIFO First In First Out

FPGA Field Programmable Gate Array (Programmable Logic Device)

GUI Graphical User Interface

HDMI High Definition Multimedia Interconnect



Acronym Meaning

HMI Human Machine Interface

Hz Hertz (cycles per second)

I2C Inter-Integrated Circuit

IC Integrated Circuit

IMU Inertial Measurement Unit

LCD Liquid Crystal Display

MEMS Microelectromechanical Systems

NTSC National Television Systems Committee

PAL Phase Alternating Line

PC Personal Computer

PCB Printed Circuit Board

PLL Phase Lock Loop

SDRAM Synchronous Dynamic Random Access Memory

SPI Serial Peripheral Interface

SRAM Static Random Access Memory

SSRAM Synchronous Static Random Access Memory

TFT Thin Film Transistor

USB Universal Serial Bus

VGA Video Graphics Array (A display format as well as a display connector)

VHDL VHSIC Hardware Description Language

VHSIC Very High Speed Integrated Circuits

1.3 Course Overview

As a requirement for graduation from Calvin College's Engineering Program, all students go through a

course titled Senior Design. The purpose of this course is to give senior engineering students an

opportunity work on a design of their own through the entire design process. All students divide into

groups of 3-5 depending on the size of the project they are working on. Throughout the course of their

senior year, each group must come up with a design idea, develop an implementation plan, identify

project requirements, come up with alternatives, make design decisions, and if possible, construct a

prototype. Each group reports to a Calvin engineering professor who provides the team with advice and

accountability throughout the year. At the end of the year each group presents the results of their work to

the Calvin community with a poster and a demonstration session open house. The group will also present

to their family and friends with a formal presentation. Additionally, two reports are required for the class,

one at the end of each semester. The first report, the Project Proposal and Feasibility Study (PPFS) is due

at the end of the fall semester and gives an introduction of the project, current design plans, and the

results of any tests that have been carried out. The Final Report, due at the end of the spring semester, is a

complete report of the project and the work done throughout the year to finish it. This document is the

PPFS submitted at the end of the fall semester.



1.4 Team Information

The senior design team is comprised of four senior engineering students in the electrical and computer

concentration. The team is pictured in Figure 1.

Figure 1. Photo of Team 3 (Arnold Aquino, Dan Ziegler, Walter Schnoor, Dan Bosscher)

1.4.1 Arnold Aquino

Arnold is an Engineering student in the Electrical and Computer concentration. His favorite part of the

Engineering program has been the analog oriented classes from his junior year. He likes to work with

transfer functions, filters, and amplifiers. Outside of the engineering program, Arnold also works on

music production and composition. He enjoys playing video games in his free time, mainly racing

simulation and music rhythm games. He is also the president of the Calvin student chapter of IEEE.

Arnold currently works part time at Dematic and has also accepted a full time position after graduation.

At Dematic, he programs programmable logic controllers and drafts using AutoCAD. For this project,

Arnold’s main goal is to design the sensor circuit and the data acquisition unit.

1.4.2 Dan Bosscher

Dan is a senior Engineering student in the Electrical and Computer concentration at Calvin College.

Along with his engineering degree, he is planning on graduating with a minor in mathematics. Dan is

currently working part time at Johnson Controls where he has been an intern for the past two summers.

Dan is also a member of Calvin College Wind Ensemble, where he plays the euphonium. In his free time,

Dan enjoys running (mainly road racing), reading, and playing video games. He is not sure what his plans

are after graduation, but is applying to a variety of engineering positions, graduate schools, and urban

education programs (such as Teach for America or Memphis Teacher Residency).

1.4.3 Walter Schnoor

Walter is a senior Engineering student in the Electrical and Computer concentration at Calvin College.

Walter has worked for Johnson Controls in Holland, MI designing functional testers for automotive



electronics. In addition, Walter has professional experience as a network analyst in healthcare as well as

professional experience in audio and video production. Walter brings to the team a technical background

in video systems and signal flow, as well as organizational and communication skills. In his free time,

Walter enjoys working on late model muscle cars, listening to country music, and helping others with

technical problems. Upon graduation, Walter will be taking a position in applications engineering with

Texas Instruments in Dallas.

1.4.4 Dan Ziegler

Dan is a senior Engineering student in the Electrical and Computer concentration Calvin College. He

currently works as an intern at Dematic doing CAD design, automation software design, and data

collection software. He also enjoys playing and modifying video games as a hobby. He brings varied

experience with software design and virtual environment programming to the project. His section of the

project is the virtual environment and the hardware-software interfaces.

2 System Architecture

The 3D simulation helmet will be designed as a human machine interface to a simulated environment on a

personal computer. Therefore, the system will have two-way communication between the computer and

the user. The computer will communicate with the user through a display system, and the user will

communicate back to the computer through head movement.

The system consists of 3 main subsystems. The system is divided according to the kind of data that is

processed or converted in the subsystem. Data flows through the subsystems as physical, electrical, or

visual data. The first subsystem is the head tracker. The head tracker subsystem includes the inertial

measurement unit and the data acquisition unit. The head tracker subsystem converts the physical

movement to electrical signal data that software can utilize. The next subsystem is the software. The

software subsystem includes the head tracking software and the virtual environment software. The

software subsystem processes the digital data from the head tracker subsystem and outputs the appropriate

video data. The next subsystem is the display system. The display system includes the video processor

and the screens. The display system uses the video data from the software and outputs the data to a pair of

screens as visual information.

2.1 Overall System

The 3D simulation helmet will have two physical components. The first will be the helmet itself. The

helmet will house the stereoscopic LCD array, as well as the inertial measurement unit (IMU) for the head

tracker. The second component will be the system interface module (SIM). The SIM will consist of a

printed circuit board and power supply assembly. The printed circuit board will contain the hardware to

drive the stereoscopic LCD array and the data acquisition (DAQ) hardware to capture the input from the

IMU. The 3D simulation helmet will also connect to a personal computer which will generate the virtual

environment. The high-level system interconnection can be seen in Figure 2 on the following page.



HELMETSYSTEM INTERFACE MODULE

(SIM)

INERTIAL

MEASUREMENT UNIT

(IMU)

DISPLAY

PERSONAL

COMPUTER

Graphics

Data

Graphics

Data

VIRTUAL ENVIRONMENT

SOFTWARE

HEAD TRACKING

SOFTWARE

DATA ACQUISITION

UNIT (DAQ)

VIDEO PROCESSOR

Data

Display

System

Head

Tracker

Software

Head Tracking Signals

Display System Signals

Software Signal

Physical Element

Figure 2. High Level System Interconnection

As shown in Figure 2, there will be some overlap between electrical subsystems. The system interface

module will be performing both the video processing component of the display system and the

communication between the inertial measurement unit (IMU) and the PC.

2.2 Head Tracker

The head tracker can be divided into two main components: an IMU and a data acquisition unit. The IMU

will consist of sensors that convert physical movement to electrical digital data. The data acquisition unit

is responsible for converting the electrical data to a format for transmitting to the computer.

2.3 Software

The software can be divided into two main components: the head tracking software and the virtual

environment simulator. The software will create and simulate a virtual environment. The software will

receive the incoming motion measurements and use them to adjust the position of the view of the virtual

environment. The software will output the display signal of the virtual environment to the video

processor.

2.4 Display System

The display system will take the video input from the personal computer and using it to drive the display.

The input video signal will need to be processed in order to be displayed in three dimensions.

3 Requirements

The requirements for the project are separated into functional, electrical, physical, power, and safety

requirements. The requirements also include design norms which are considerations the team imposed

upon the design. These considerations are moral guidelines for the engineering ethics applied to the final

design.1



3.1 Functional Requirements

In this section, the system as a whole is referred to as “the device.”

REQ 3.1a: The device shall have a power on/off button.

REQ 3.1b: The device shall display in three dimensions.

REQ 3.1c: The device shall track the motion of the user’s head.

REQ 3.1d: The device shall have a method of calibration.

3.2 Electrical Requirements

The project is subdivided into three main systems: the head tracker, the display system, and the virtual

environment. The electrical requirements are described in terms of each of the three main systems.

3.2.1 Head Tracker

REQ 3.2.1a: The head tracker shall be connected through a USB Type A connector

The USB Type A connector is a very common device connector on personal computers.

REQ 3.2.1b: The head tracker shall be able to detect rotation and movement along the x-axis, y-axis, and

z-axis.

The acceleration shall be measured up to 6.7 g’s.2 The angular velocity shall be measured up to 800

degrees per second (See Appendix A). The sensor shall detect an acceleration minimum of one hundredth

of the acceleration due to gravity to avoid a jittery output. The sensor shall detect an angular velocity

minimum of one hundredth of a degree per second.

3.2.2 Software

REQ 3.2.2a: The software shall be supported by Windows XP SP2 or later Windows operating systems.

The software shall run on Windows XP SP2 or later because, based on the team’s research, 93% of the

personal computer market share belongs to machines that fit into this category.3

REQ 3.2.2b: The software shall be able to run the virtual environment and head tracking programs

independently.

This means that the head tracker and virtual environment programs are two separate programs. It also

means that the head tracking program can be run without the virtual environment program being run and

vice versa. This is important to the customer for modularity of the input interface and the virtual

environment software. If the programs are independent, the user can purchase our system even if they

already have an established virtual reality training program.



REQ 3.2.2c: This software shall be able to simulate the virtual environment using a physics engine.

This requirement states that the software shall be able to accurately depict the user’s movement through a

virtual environment by applying mathematical models of physical laws. The physics engine is necessary

for the user’s immersion in the virtual environment.4

REQ 3.2.2d: The user interface for creating the virtual world shall be graphical and not require

programming language knowledge.

This is necessary to expand the target market and to assure the product can stand alone without the user

needing to hire a programmer.

3.2.3 Display System

REQ 3.2.3a: It shall accept an input video stream in a 3D format, and contain the necessary components

to display the video output in 3D.

REQ 3.2.3b: The displays shall be mounted on the helmet.

The 3D simulation helmet is defined as a head mounted display. The helmet will be the physical

component worn by the user of the headgear.

REQ 3.2.3c: The display system shall be able to accept a common signal format used in AV and

computing.

For the system to be successful from a business perspective, the device needs to be able to connect to a

common AV format that is used on desktop and laptop personal computers running Microsoft Windows.

REQ 3.2.3d: The display system shall input a resolution of at least 640x480 pixels resolution.

This is the minimum effective resolution for Microsoft Windows.5

REQ 3.2.3e: The display system video shall have a frame rate of 30 frames per second.

A frame rate of 30 frames per second is beyond the persistence of vision, and a higher frame rate would

not provide any performance benefit to the user.

3.3 Physical Requirements

There are a number of restrictions on the physical design of the project. Many of these requirements are

based on improving the user experience and preventing injury while the product is in use.

3.3.1 Product Weight

REQ 3.3.1: The system shall place a load on the user's head of no more than 2.0 lbs.

If the product weighs too much it would cause discomfort or even injury to the user. The limit of 2.0

pounds is an estimate of what the weight limit should be. The team will run initial weight tests on team

members during interim, and will have run a more extensive test on unbiased groups not connected to the

team by the end of interim.



3.3.2 Product Shape

REQ 3.3.2: The product shall have a shape that is balanced over the user's head.

An unbalanced product can apply torque to the user’s neck; this can affect the motion of the user’s head

possibly causing discomfort or injury for the user. Balanced means that the product shall not cause

torques on the neck that could cause discomfort, even after extended continuous use. Research provided

maximum neck torques of 54.38 Nm for lateral flexion along the coronal plane (returning head to vertical

from being tilted to the side), 56.37 Nm for extension torque along the sagittal plane (returning head to

vertical from being tilted to forward), and 29.10 Nm for flexion torque along the sagittal plane (returning

head to vertical from being tilted back).6 These measures, however, are the maximum load the neck can

bear and the group must define the requirement for comfort.

The team will run initial torque tests on team members during interim, and will have run a more extensive

test on unbiased groups not connected to the team by the end of interim.

3.3.3 Product Materials

REQ 3.3.3a: The helmet shall be made of recyclable materials.

The use of recyclable plastics is necessary for the team be good stewards, limiting the amount of waste

generated by the product.

REQ 3.3.3b: The product shall avoid use of materials that would be harmful to the environment. If this

cannot be achieved the team shall publish proper disposal methods for users.

The use of non-toxic materials is necessary to minimize the impact of the product. However, if a required

part cannot be acquired without toxic materials (if the sensor break-out boards did not use lead-free circuit

design), this impact could also be minimized with proper disposal methods. Either way, the team needs to

address this in the design.

3.4 Power Requirements

REQ 3.4a: The power supply shall provide at least as much voltage as the greatest voltage for a single

part.

REQ 3.4b: The power supply shall provide at least as much current as the combined maximum current

draw of all included parts.

These requirements will be specified during interim, when the team has finalized the parts list.

REQ 3.4c: The power supply shall contain a current-limiting fuse.

This requirement is to protect the device from an internal short circuit which could potentially injure the

user and damage the device.



REQ 3.4d: The power supply shall be AC mains isolated.

This requirement provides the device with isolation from the higher voltage mains to protect against high

voltage shock.

REQ 3.4e: The power supply shall accept 110-120 volts of alternating current at 60Hz.

This requirement is to enable the device to be supported by North American power standards.

3.5 Safety Requirements

It is imperative that the product is safe for the user under normal conditions. Therefore, it is necessary to

identify potential hazards and what can be done to avoid them. It is also important for the team to

communicate to the user what hazards he or she shares responsibility for preventing (proper use of the

device). The team wants its customers to be able to trust that, when used properly, the product can be a

safe and helpful tool. The team feels the best way to create this trust is by open communication about the

product.

3.5.1 Electrical Safety

REQ 3.5.1a: The product shall use insulated wiring and mount electrical components in a manner such

that the user will not be able to access them.

If any electrical parts or wires are exposed, there is a potential for shock damage to the part, and

discomfort or injury for the user.

REQ 3.5.1b: The product shall also have relatively low power for the safety of the user.

The perceptible current for humans is 1 milliamp. The user shall not perceive any current from the

helmet.7

3.5.2 Physical Safety and Health Concerns

REQ 3.5.2a: The user shall be notified of safe usage of the product and potential safety risks.

There are certain situations and people who should not use this product (people with epilepsy or prone to

seizures). These situations will be made known to the user through a manual and a splash screen on start-

up.

REQ 3.5.2b: The maximum delay (lag) of the system shall be 33 ms.

If the system delay is too great, the user can develop headaches or motion sickness from the motion being

out of sync with the video. The video output is 30 frames per second, and the input can only be realized

by the display once every 33 ms (the frame period).

3.6 Design Norms

Design decisions cannot be merely objective, but must be considered in their societal context. Other

people will be affected by the decisions that the team makes. Therefore, we need to be considerate of



other people in our design. Several things that we are focusing on in our design when we consider how

other people interact with our product are humility, trust, integrity, and stewardship.

3.6.1 Designing for Humility

The goal for the team is to provide a 3D simulation headgear that would provide the user with an

immersive, lifelike experience. However, the team recognizes that the technology it is using has

limitations, and will not be able to create a flawless simulation of any event. The team feels it is important

to recognize the limitations of the system and to be open about these limitations with the customer, so that

the customer does not expect more of the product than it can provide.

3.6.2 Designing for Trust

Because we are designing our product to be used as a simulation tool, it is important that we can

accurately represent any situation a customer might want. Users of this product will need to be

able to trust it to make an accurate representation of what they try to simulate with it. If they

cannot trust our product, it will not be useful to them as a training tool and will reflect poorly

upon the designers.

3.6.3 Designing a Product of Integrity

We want our design to be intuitive to use. When simulating any situation, you want to be able to interact

with the simulation the same way you would interact with the real world. For example, when we change

what we look at in real life we turn our head. A major portion of our project is emulating this same

behavior, so that when users turn their heads, their view of the environment will change.

3.6.4 Designing as Stewards

As Christians, we are called to take care of God's creation and use the resources of the world responsibly.

Furthermore, we live in a world of limited resources. Therefore, we feel it is important to make as small

of an impact as possible with our product. We want to minimize the amount of power that our product

uses in effort to use the world's resources responsibly. For this same reason, we want to use recyclable

materials as much as possible in our product. This allows our product to be disposed of in a sustainable

way. However, it cannot be assumed that the user will dispose of the product properly; therefore we want

to use toxin free materials in our design to reduce the environmental impact if our device ends up in a

landfill. One way we can accomplish this is through the use of lead-free circuit boards.

4 Electrical System Specifications

The electrical components of the system will primarily reside in the system interface module. The current

design consists of a field programmable gate array (FPGA) device at the center of the design. The display

system was chosen to be a stereoscopic display consisting of 2 LCD displays at 320x240 pixels. The

system interface module block diagram can be seen in Figure 3 on the following page. The configuration

seen in Figure 3 allows for customization after physical construction. The head tracker and display

system share the resources of the FPGA. The design process and alternative designs for each subsystem

(Display System, Head Tracker, and Software) are detailed in this chapter.



ALTERA

CYCLONE II FPGA

PIXEL BUFFER A

512kB SRAM16-Bit 1 Plane 320x240

PIXEL BUFFER B

512kB SRAM16-Bit 1 Plane 320x240

INERTIAL

MEASUREMENT UNITDIGITAL OUT

CLOCK 50MHz

INPUT VIDEO

DECODERTV-VIDEO NTSC

Hardware Video

Processor

On-Chip Memory

16KB

NIOS II CPU

32-bit SoftcorePhase Lock Loop

UART RS-232

SERIAL DRIVER

USB UART

JTAG to USB

RIGHT LCD DRIVERLEFT LCD DRIVER

SYSTEM INTERFACE MODULE (SIM)

Data Interface to

Software System

Graphics Interface to

Software System

Data Interface to

Head Tracker

LEFT LCD RIGHT LCD

Figure 3. System Interface Module Block Diagram

4.1 Head Tracker

The head tracker consists of sensors and a data acquisition unit. The sensors convert physical movement

to electrical signals. The data acquisition unit communicates with the computer through its own

communication protocol. A block diagram of the proposed head tracker can be seen in Figure 4.

ALTERA CYCLONE II FPGA

DATA ACQUISITION PROCESSING MODULES

NIOS II

SOFTCORE 32-BIT

MICROPROCESSOR

ON CHIP MEMORY

UART MODULE

AVALON

I2C MODULE

AVALON

AVALON

UART I2C

OUT TO PERSONAL

COMPUTER

USB

I2C BUS

3-AXIS

ACCELEROMETER

3-AXIS

GYROSCOPE

I2C

I2C

USB TO UART

Figure 4. Head Tracker Block Diagram



4.1.1 Sensors

The team must select sensors that can track the specific types of movement for the application of the

helmet. Sensors that convert physical movement to electrical signals have been around for a long time and

have had time to grow into different markets.

4.1.1.1 Problem Specification

The team needs to map out the location and orientation of the user’s head. The device needs a way for the

software to tell at what rate and in which direction the user’s head is moving. This physical movement

must be measured in three dimensions. This means that a physical to electrical conversion system is

needed to translate the physical movement into a set of data. The sensors will communicate with the data

acquisition unit which then communicates with the software to map out the location and direction of the

user’s head.

4.1.1.2 Alternatives

The following table shows possible technologies that can be used to motion tracking.

Table 2. Head Tracker Technology Alternatives

Technology Description

3D Scanner Uses depth sensors and infrared lasers to reconstruct a 3D image

Magnetic Fields Emitting magnetic fields and uses magnetic field sensors to determine

location

MEMS Uses independent sensors

Camera Image

Tracking

Uses stereo image comparison between frames from a camera to

determine rate of movement.

4.1.1.3 Decision Criteria

Size/Weight - The sensors used for the tracking must be small. Ideally, the sensors would be less

than a square inch for small board footprint on the circuit board. The circuit board that the sensors

are mounted on will be attached to the helmet itself. Too much weight could put a strain on the

user’s neck (See section 3.3.1). Small sensor size will also add to the aesthetics of the final

product.

Setup Complexity - The team also aims for the product to be easy to set up. External sensors will

tend to have more complexity for usage such as limited product usage area and orientation.

Design Type – This criterion refers to whether the design will be software or hardware based. The

team aims to design more hardware and hardware interface than software.

4.1.1.4 Design Selection

Motion-sensing technology that requires emitters such as infrared or magnetic field emitters will not be

feasible because setup for such a system is too complicated. Another possible technology is visual

tracking. This requires mounted cameras on the helmet. The problem with this alternative is that it would

mostly be a software design which is not the goal of this project. Another type of image tracking

technology is a 3D scanner. These types of scanners are external sensors that calculate depth using



stereoscopic cameras. The Microsoft Kinect system uses 3D scanners for head tracking. This type of

technology has the same problem as the visual tracking because it is centered on software design.

The team decided to use MEMS (microelectromechanical systems) technology sensors. These sensors are

used in many consumer electronic devices such as video game controllers and smart phones. They are

also used for larger scale applications such as vibration measurements for bridges, buildings, and other

structures. These sensors are small and compact which means that it will be easy to mount to the user’s

head while making the extra weight unnoticeable. Finally, the cost for MEMS sensors has decreased over

the years because of the continuously growing market.

The MEMS sensors that the team decided on are accelerometers and gyroscopes. The accelerometers are

important in measuring the linear acceleration of the head. 3-axis accelerometers are ideal to measure

movement of the user in three directions. For example, if the user jumps or crouches, an accelerometer

measuring the Z-axis is required. If the user moves forward and backward, an accelerometer measuring

the Y-axis is required. If the user strafes left and right, an accelerometer measuring the X-axis is required.

In addition to measuring the movement along each axis, the sensors also need to measure the rotation

around each axis. Rotation around the X-axis needs to be measured when the user looks up and down. If

the user looks left or right, the rotation around the Z-axis needs to be measured. Finally, if the user tilts his

or her head, the sensors need to measure the rotation around the Y-axis.

With the accelerometer and gyroscope, the total sensor circuit has six degrees of freedom. This is just

enough to map out the movement of any unit in a three dimensional space. The team also considered

adding a magnetometer to the sensor unit. A magnetometer would tell the software the direction of true

North. This is useful in recalibration. However, it is only useful for recalibration in the X-axis and Y-axis.

The added cost for a breakout board and production cost were too much for the limited added

functionality. Therefore, the team decided not to include a magnetometer, as it is not necessary for the

product to function correctly.

4.1.1.5 Implementation

The chosen sensor technology presented the need to select a specific sensor.

4.1.1.5.1 Alternatives

The MEMS sensors the team selected are accelerometers and gyroscopes as mentioned in section 4.1.1.4

Design Selection. Decisions needed to be individually made as to which accelerometers and gyroscopes

will be selected.

4.1.1.5.1.1 Accelerometers

The team found Accelerometer devices from electronic component distributors such as Avnet8 and

DigiKey9. The table on the following page shows the devices along with their electronic characteristics

and device specifications.



Table 3. Accelerometer Alternatives

Manufacturer Part No. Unit

Cost

($)

Breakout

Board

Cost ($)

Output

Signal

Supply

Voltage

(V)

Acceleration

range (+/- g)

Bandwidth

(Hz)

Current

Consumption

(µA)

Analog Devices ADXL335 3.22 24.95 Analog 1.8 - 3.6 3 550, 1600 350

Analog Devices ADXL345 13.67 27.95 I2C or SPI

2 - 3.6 2, 4, 8, 16 6.25 - 3200 145

Bosch BMA180 3.108 29.95 I2C or

SPI

1.6 - 3.6 1, 1.5, 2, 3, 4, 8,

16

10 - 1200 640

STMicroelectronics LIS331HH 3.604 27.95 I2C or

SPI

2.16 - 3.6 6,12,24 50 - 1000 250

Freescale Semiconductor

MMA7361L 1.275 19.95 Analog 2.2 - 3.6 1.5,6 300, 400 600

VTI Technologies SCA3000-D01 16.88 44.95 SPI 2.35-3.6 2 45 480

4.1.1.5.1.2 Gyroscopes

The team decided to use 3-axis gyroscopes for reasons explained in the next section 4.1.1.5.2

Implementation Decision Criteria. Specifications for some or the gyroscopes that fit the criteria can be

seen in Table 4 below.

Table 4. Gyroscope Alternatives

Manufacturer Part No. Unit

Price

($)

Breakout

Board

Cost ($)

Output

Signal

Supply

Voltage

(V)

Angular

velocity range

(degrees/s)

Bandwidth

(Hz)

Current

Consumption

(mA)

STMicroelectronics L3G4200D 6.353 49.95 I2C or

SPI

2.4 - 3.6 250, 500, 2000 100 - 800 6.1

Invensense ITG-3200 10 49.95 I2C 2.1 - 3.6 2000 1000 6.5

VTI Technologies CMR3000-D01 7.5 N/A I2C or SPI

2.5 - 3.6 2000 20 - 80 5

4.1.1.5.2 Decision Criteria

The criteria used for selecting sensors are described below. The criteria were given weights based on

importance to the project. The team used these weights in the decision matrices in sections 4.1.1.5.3.1

Accelerometer Design Selection and 4.1.1.5.3.2 Gyroscopes Design Selection.

Unit Cost [7] – The cost for each unit made for a large volume production.

Breakout Board cost [9] – The cost for a breakout board. A breakout board is used to wire up the

chip easily. The pins for the chip are too close together because they are surface mount chips.

Therefore, breakout boards make it easier for the developer to design and test the head tracker

circuit.

Interface/Output Signal [7] – The interface is the type of output signal that the sensor circuits

have. These include analog, digital SPI, and digital I2C. The interface is important because it

determines how the data acquisition unit is laid out. For example, for an analog interface, the

team would need to include an Analog to Digital converter.

Bandwidth [6] – The bandwidth is the rate at which data can be read from the sensors. Generally,

the team is looking for high bandwidth in order to process the information accurately and output

the results to the video as quickly as possible. The minimum bandwidth has yet to be determined.

The minimum bandwidth depends on the rate at which the software processes the sensors’ data

and outputs to the video processing unit. If this rate is higher than the rate that the set of data (x,

y, and z components) is read from the sensors, then the sensor bandwidth is the limiting factor

which causes noticeable delays in the data flow. After testing sensors with bandwidth of 800Hz,

the response was pretty accurate with no noticeable delay.



Number of Axes – The number of axes represents the freedom of movement. The team wants

three axes of motion to be detected for both the accelerometer and the gyroscope. The team is

also looking for sensor circuits that have as many axes in one chip as possible. The reason for this

is to keep the reference point the same for all three axes. For instance, the pitch, yaw, and roll

zero reference point should be the same point so as to not overlap data.

Range [8] – The range refers to how accurate the sensors sense linear movement or rotational

movement. The accelerometers measure up to a certain acceleration represented by a number of

g’s (a fraction of that acceleration over the gravitational acceleration constant). The gyroscopes

have measurements in degrees per second. The team is looking for the range of measurement

greater than or equal to the range of movement of a human head. Humans rarely experiences

forces greater than 6.7 g’s10

, so the product would not need to detect accelerations greater than

this. The team measured the average rotational speed of the human head to be 253.3 degrees per

second and the maximum rotational speed of 842.1 degrees per second. (See Appendix A) Since

the user of the helmet is not likely to use the helmet near the maximum rotational speed, this

limits the amount of rotation the gyroscope needs to detect.

Power [5] (current consumption) – This refers to the power consumption of the circuits. Since this

project is tethered to a power supply (not battery powered), the team was not concerned with

specifically low power applications. However, power consumption is still taken into account in

order to be good stewards of electricity as well as for heat considerations.

Datasheet [6] – This criterion refers to how understandable the datasheets are. Datasheets that

have complete electrical and physical specifications would help the team design other parts of the

project, such as power requirements for example. Also, the team prefers datasheets that contain

detailed information on interaction with the devices. The team considers language and format

when reading datasheets. Usually devices from the same manufacturer follow the same format on

datasheets. The process of communicating with the device will be similar for both which will cut

down design time.

4.1.1.5.3 Design Selection

The team chose to work with accelerometers and gyroscopes that were available as breakout boards. If the

team would choose sensors without breakout boards, the team would have to pay for the sensors to be

surface mounted to a custom board and wait for the process to be completed by an outsourced company.

Sunstone charges $28 for a 1” x 1” board. The board can be completed in 3 – 5 days if it is expedited, but

this would increase the board cost. The design time for the PCB would also be lost time that could be

used to work on other portions of the project. Sensors that are available as breakout boards help speed up

the development and keep cost down. The team found a variety of sensors from the company SparkFun11

.

For the high volume production, parts will be ordered from Digikey12

.

At first, team member Arnold Aquino decided to work with analog interface sensors because of his

background with analog devices and experience using analog accelerometers. However, after consulting

professors and the team’s industrial consultant, the team decided that using digital sensors is the more

logical choice since the data has to be converted to digital data for the software. This speeds up the team’s

development by removing an unnecessary element from the system.

As mentioned in the previous section, collecting information on all three axes is preferred. It is also

possible to use three different one-axis chips. However, this would add to the complexity of the system

because it would require more clocks and interfaces involved in the data acquisition unit.



4.1.1.5.3.1 Accelerometers

The following table shows the decision matrix for the accelerometers available based on the design

criteria mentioned in the previous section.

Table 5. Accelerometer Decision Matrix

Alternative Unit

Cost

Breakout

Board Cost

Interface Range Bandwidth Power

Consumption

Datasheets Total

Criteria Weight 7 9 7 8 6 5 6

Analog Devices

ADXL335 Score 90 90 60 40 60 80 80 500

Weighted 630 810 420 320 360 400 480 3420

Analog Devices

ADXL345 Score 20 85 100 90 100 100 60 555

Weighted 140 765 700 720 600 500 360 3785

Bosch

BMA180 Score 80 70 100 100 95 50 90 585

Weighted 560 630 700 800 570 250 540 4050

STMicroelectronics

LIS331HH Score 75 85 100 70 90 90 100 610

Weighted 525 765 700 560 540 450 600 4140

Freescale Semiconductor

MMA7361L Score 100 100 60 50 50 60 90 510

Weighted 700 900 420 400 300 300 540 3560

VTI Technologies

SCA3000-D01

Score 10 40 80 40 20 70 70 330

Weighted 70 360 560 320 120 350 420 2200

The STMicroelectronics LIS331HH scored the best in terms of the design criteria. Even though there was

a small margin between the LIS331HH and the Bosch BMA180, the LIS331HH was compatible with an

available gyroscope. The compatibility with the manufacturer’s devices meant that a single design for

communication is possible. The interface and addressing for a Bosch accelerometer is not similar to any

of the gyroscope alternatives.

4.1.1.5.3.2 Gyroscopes

The team found three 3-axis gyroscopes. They also found 2-axis and single axis gyroscopes. The lowest

cost for a dual axis gyroscope breakout board was $29.95. The lowest cost for a single axis gyroscope

breakout board was $19.95. Purchasing these two breakout boards would be $0.05 cheaper than the 3-axis

gyroscope breakout boards. However, as previously mentioned in the number of axis criteria in section

4.1.1.5.2 Implementation Criteria, a single 3-axis device is preferred because of the singular point of

reference for measurement. Also, the team only needs a single communication design if they use a 3-axis

device. The table on the following page shows the decision matrix for the gyroscopes based on the design

criteria mentioned in the previous section.



Table 6. Gyroscope Decision Matrix

Alternative Unit

Cost

Breakout

Board Cost

Interface Range Bandwidth Power

Consumption

Datasheets Total

Criteria Weight 7 9 7 8 6 5 6

STMicroelectronics

L3G4200D Score 100 100 100 100 90 90 100 680

Weighted 700 900 700 800 540 450 600 4690

Invensense

ITG-3200 Score 60 100 90 90 100 80 90 610

Weighted 420 900 630 720 600 400 540 4210

VTI Technologies

CMR3000-D01 Score 90 0 100 90 60 100 90 530

Weighted 630 0 700 720 360 500 540 3450

Using the decision matrix above, the team chose the STMicroelectronics gyroscope because of its highest

weighted score. The L3G4200D is similar to the accelerometer selected. Both devices are designed and

manufactured by STMicroelectronics. The datasheet for L3G4200D was scored highest because it was

similar to the datasheet for the LIS331HH.

4.1.2 Data Acquisition

The data acquisition unit is important because the sensors have different communication protocols than

what the user’s computer recognizes.


The sensors will have an I2C interface as mentioned in section 4.2.1.5.3 Implementation Design Selection.

The software cannot receive the data from the sensors directly. A data acquisition unit is needed to

organize the sensor data into packets that are accepted by the input interface.


The team narrowed the choices for a data acquisition system to either an FPGA or a microcontroller. The

FPGA would be the same FPGA used for video processing (See Section 4.3.2.5 FPGA Implementation).

Other data acquisition system alternatives include different microprocessors and data acquisition PCI

cards. The table below shows examples of data acquisition systems.

Table 7. Data Acquisition Alternatives

Manufacturer Model Type

Arduino Uno Microcontroller

Altera Cyclone II FPGA

National Instruments PCI-6601 Data Acquisition PCI


The data acquisition system must be able to be used in laptops and desktops using existing ports. The

communication protocol available between the computer and the data acquisition unit is another criterion.



This criterion has implications on what type of connector can be used between the computer and the

device. Possible communication protocols include RS232, USB, IEEE 1394 Firewire, and Bluetooth.

The communication protocol between the sensors and the data acquisition system will be I2C which the

data acquisition system will have to support. Simplicity is valued since the team is limited in design time.

A small circuit board footprint is also preferred.


The team chose to use an FPGA. While an Arduino microcontroller can be used for data acquisition, the

team decided that an FPGA would present a better challenge and learning experience. Also, using an

FPGA would mean that the data acquisition system can be integrated with the system interface module

(SIM). The team has good experience with building custom systems in an Altera Cyclone II FPGA.

Adding components on the board would present a good challenge. On the other hand, programming using

an Arduino microcontroller is simpler due to the libraries available in the Arduino development

environment. The team has already been able to acquire data from sensors using I2C on an Arduino

microcontroller. The code contains a library called “Wire.h” which includes an I2C interface. Therefore, a

microcontroller can be used as a backup data acquisition system if implementing the DAQ in the FPGA

ends up being more complicated than the team expects.

Since the system interface module will be tethered to a computer because of the video processing unit,

using wireless communication is unnecessary. The team ruled out Firewire because the Altera

development board that the team is using does not include a Firewire driver/receiver.

The choice came down to the USB communication protocol and RS232 communication protocol. While

USB is used in almost all types of personal computers and devices, the team chose RS232 instead. Even

though the Altera development board includes a USB driver/receiver, the USB Intellectual Property core

requires a license to be purchased from System Level Solutions. Furthermore, the device driver and

receiver for the RS232 (Max232) costs $0.66 per unit as opposed to $9.68 per unit for the USB controller

(ISP1362).

The team understands that most computers do not have a serial port but have a USB port. With the RS232

communication, the team can use a USB connector instead of a serial port. This is possible by using a

USB-UART IC such as a FTDI FT232B which has a $4.50 unit price. This IC still cost less than the USB

controller. The FT232B is a USB to serial UART interface.

4.1.3 System Integration

The sensors and data acquisition unit will essentially take the physical movements from the inertial

measurement units (gyroscope and accelerometers), convert the signals to binary, organize the binary data

into packets, and then store them in a buffer. The gyroscope and accelerometers will be connected to the

NIOS II CPU using I2C protocol. The data acquisition unit will receive requests from the input interface

in the PC and send the data to the computer via the RS232 communication protocol using a USB

connector.

4.1.4 Testing

The head tracker will be tested by physically putting the sensors along different orientations and

movements. The maximum and minimum range of the linear acceleration of the accelerometer sensors

will be tested using physical movements. Also, the maximum and minimum range of the angular velocity

of the gyroscope sensors will be tested using physical movements. The operating movements (movements



of the human head) will also be tested for accuracy and precision. One important element of the devices

that should be tested and accounted for is the linearity of the data. The effect of the acceleration due to

gravity should also be accounted for.

4.2 Software

The architecture of the PC portion of the project is mainly broken into 3 subsystems: the input interface

software, the input mapping software, and the virtual environment software. Each of these systems must

work together to give a consistent flow of data from the user to the CPU and back to the user. This data

flow can be seen in Figure 5 below.

User Windows PC

OUTPUT VIDEO

Input Mapping

Software

Virtual

Environment

SimulatorInput Interface

Operating

System

(Microsoft

Windows)

ACTUAL

MOUSE

INTEGER DATA STREAM

MOUSE EMULATION

Win32 API

Win32 API MOUSE INPUT

USB SERIALTV-VIDEO NTSC

SUMMED

MOUSE

POSITION

Win32 API

640x480 GRAPHICSSERIAL DATA STREAM

+

USB

MOTION TRACKING DATA

Figure 5. Software Architecture Block Diagram

The CPU must run all three of these systems at the same time to give an accurate simulation, but must

also be able to run them separately for more functionality. If the 3D simulation helmet is used for non-

simulation applications such as video games, the user may want to disable the motion tracking in order to

get stereoscopic vision while using a traditional controller. Conversely, if the user needs to calibrate the

motion tracker with the pointer, they may want to turn off the stereoscopic aspect in order to better see the

2D desktop for alignment.

The input interface is an interface for acquiring the data that is collected in the data acquisition (DAQ)

portion of the system interface module (SIM). The SIM will be collecting and formatting the data from

the motion tracker and storing the data to its memory. The input interface will request data from the SIM

as to the position of the user’s head. The interface will interpret the data from the SIM and then give that

interpreted information to the input mapping software.

The input mapping software is used to take data regarding the position of the user’s head and to translate

that data into a format the environment software can understand. The base case for mapping is simple

pitch and yaw to vertical and horizontal mouse movements, respectively.

The virtual environment software includes both an intuitive graphical interface for designing a virtual

environment as well as a physics engine for realistic simulation. The simulation aspect is then controlled

by using the emulated mouse cursor movements to look around in 360 degrees. The inclusion of roll will

also allow for tilting of the head. The environment software continuously updates the view of the virtual

environment and outputs in a video data format to the video processing part of the SIM.



The main design decisions pertaining to the software were what should be written and what needed to be

acquired. This acquisition then broke down into what needed to be bought and what open-source

software could be utilized. Creating all three sections from scratch would have been a project beyond the

scope and aim of this project. It is beyond the aim because this would be more in the computer science

realm and beyond the scope because it would take significant time and effort to create. The virtual

environment software alone requires a graphical user interface (GUI) for designing virtual environments,

a rendering engine for creating the graphics, and a physics engine for allowing simulation. This would

take estimated 10,000-50,000 lines of code to implement and several months of man-hours to code.13

This does not count research and learning curve for these different applications of code. Therefore,

identifying which parts of the project could be bought or open-sourced successfully was the first key

design decision for the software. If the decision was made to write the code, then the following design

decisions were about what format that writing would be in and how we would implement the function of

that software. If it was decided that we would buy or utilize open-source, then the following design

decisions were about which software would be the best fit for the role for the cost. This method of design

steps can be applied to each of the three major portions of the software application.

4.2.1 Input Interface

The input interface includes the sending of requests to the SIM, the receiving of data packets from the

SIM, the interpretation of the data packets, and the sending of that data to the input mapping software.

The team will define a custom transfer protocol used to send and receive data to and from the SIM. The

sending of data to the input mapping software will involve passing the data internal to the personal

computer.


The team could not acquire input interface software because it is specific to the hardware chosen in the

DAQ as well as the software to which it would pass the interpreted data. For this reason, the problem

became how we would implement this software rather than if we could acquire it.


The alternatives for this code are broken down into the programming language and the development

environment. The options identified for programming language are C, C++, and python. The possible

development environments are Eclipse and National Instruments’ LabWindows/CVI. The National

Instruments (NI) software development environment would be for developing C code and Eclipse would

be used for C++ or python code.


Criteria for the input interface have not yet been defined. No sufficient design decisions have been made

about the input interface. This is due to the dependency of the input interface function on the inputs that

have not yet been defined completely.


A design selection cannot be made until the criteria are better defined. We know that all of the members

have course work experience with C++. Additionally, Dan Bosscher has experience with Python, and

Walter Schnoor has some experience with the NI LabWindows/CVI tool. Walter also added that the NI



tool has some applicable libraries for RS232 communication. From this information, the team is has the

most confidence in the NI tool, but more information is needed before a design selection can be made.

4.2.1.5 System Integration

In order to integrate the input interface software, the inputs and outputs must be made to connect to the

software or hardware on either side of it. In the input interface software, the input is received data

packets from the SIM and this input will need to be interpreted and organized within the input interface.

The outputs of the program are requests for data to the SIM and organized and interpreted data to the

input mapping software. The interactions between the SIM and the input interface will occur via the

RS232 to USB interface. The software will also have to be integrated with the other software to make a

cohesive package by being included in the same installer and being able to be run with the other

components in a simple user interface

4.2.1.6 Testing

For this software, the testing plan will be formulated more as the definition of the software becomes more

defined. A preliminary breakdown shows that the functions for receiving and transmitting data will need

to be checked for consistency and also for accurate transmission. Also, the interpretation software must

be checked for accurate decoding through the range of values that may be output from the SIM.

4.2.2 Input Mapping

The input mapping software includes the receiving of organized and accelerometer data from the input

interface, comparing that data to previous data for changes in direction, and outputting that data in a way

that can be read by the virtual environment program. The received data will be organized into integers for

offset from the calibrated origin for pitch, yaw, and roll from the gyroscope circuit and x, y, and z

coordinates from the accelerometer circuit.


The input mapping software could be designed by the team, bought, or utilized from available open

source code.


Creating software for the function of input mapping would involve having an in-depth knowledge of the

hardware level of the system in which the program was running. Emulating the hardware, on the other

hand, can be done using basic hardware inputs that most computers already have. This gives the program

more flexibility in order to perform on various platforms. Writing a hardware emulator was decided to be

beyond the scope of the project, so the team decided to utilize open source software for this piece of

software.


The criteria that were applied to the input mapping software decisions were derived from the

requirements. The software would need to fit the necessary functionality; however, it was simply cost

driven decision. This cost, however, also included any Intellectual Property (IP) rights and restrictions

that had to be addressed for distribution. The user friendliness criterion was not applied to the input

mapping software because it will be running underneath the user’s perception. It will only be accessible

as an advanced configuration function, but not a necessary user function to be interacted with directly.




The input mapping system that was chosen was the GlovePIE hardware emulation software. Several

other input mapping programs were found, but they all simply mapped the keyboard input to a mouse

input rather than giving a programming interface in which the developer chooses how to map inputs.

These other software packages failed to meet the design requirements and for this reason were not even

candidates for this software application. The setup of the GlovePIE program is still mainly that of a

developer’s tool to create executable files that will map actual inputs to virtual outputs. The only

drawback that the team encountered in this software was that it cannot be used in baseball simulations

because it has an exclusive deal with a baseball simulation company. Baseball simulation was not a part

of the team’s initial target market, however, and for that reason this restriction was found to be an

acceptable concession.


For the input mapping software, the input is going to be pitch, yaw, and roll data from the input interface,

probably in an integer offset from a zero position. The output is a mouse type coordinate system with a

possible roll variable and will need to be emulated in order for the virtual environment software to take it

as an input. The software will also have to be integrated with the other software to make a cohesive

package by being included in the same installer and being able to be run with the other components in a

simple user interface.

4.2.2.6 Testing

For this software, the functions for computing the change in input direction will need to be checked

through the range of possible head motions. The proposed head motion is to have full range of 360

degrees in yaw, 90 degrees in both directions of pitch, and 45 degrees of roll. This test would include

checking for the data points at the extremes of the pitch and roll and the halfway points between them. It

will also test for the points around the circle of yaw every 45 degrees. This will be tested by rotating the

sensors to the desired position and comparing the values displayed in the program. Also, the sensitivity of

the output to input values will need to be checked for response time and jitter. These, however, are full

system tests and are included in section 6.

4.2.3 Virtual Environment Development and Simulation

The virtual environment software includes a graphical user interface and a physics engine. The graphical

user interface (GUI) is used for creating a virtual environment. A physics engine is used to simulate an

avatar for the user in the virtual environment. The physics engine is also used to output the user’s view in

the environment in a way that can be displayed in stereoscopic 3D. The physics engine should also

receive input that will move the user’s view, similar to mouse inputs.


The creation of virtual environment creator and simulator would have been a massive project and would

have been well beyond the scope of our project. That is why it was decided that this portion of the design

needed to be bought or found in the form of open-source software. This created the new design decision

of which of the many available virtual environment development kits should be used.




The programs that were compared as possible candidates were the Steam Source Software Developer’s

Kit (SDK), the OGRE 3D Engine, the Cafu Engine, the Blender 3D Studio, the Panda3D Game Engine,

the Unity 3 Engine, the Truevision3D SDK, and the DX Studio 3D Engine.


The criteria that were applied to the virtual environment software decisions were derived from the

requirements. The software would need to fit the necessary functionality, which includes having

rendering and shading capability for designing a visually feasible virtual environment, having a physics

engine for simulating in a world with realistic responses, and having a simple graphical user interface so

that someone without programming knowledge can create a virtual environment. The virtual environment

development and simulation software also needed to be user friendly in running the simulation because

the user would be interacting with the program directly.

Rendering [7] – Rendering refers to the ability to use the computer’s resources in order to create a

realistic looking virtual world.

Ease of Use [9] – This refers to how intuitive the developer user interface is for creating virtual

environments. The learning curve required to proficiently use the software is included in the

criterion.

Physics Engine [8] – This refers to the functionality and realism of the physics representations in

the simulation. A score of zero indicates a program without a physics engine.

Cost [6] – This refers to the cost of a development license for the software as well as the cost of

implementing the software in a product.


The following table shows the decision matrix for the virtual environment software available based on the

design criteria mentioned in the previous section.

Table 8 Virtual Environment Software Decision Matrix

Rendering Ease of Use Physics Engine Cost Total

Weight 7 9 8 6 30

Development Kit

Steam Source 5 1 7 6 19

OGRE 3D Engine 7 5 0 6 18

Cafu Engine 6 8 0 6 20

Blender 3D Suite 7 4 7 6 24

Panda3D Engine 6 2 5 6 19

Unity 3 Engine 6 3 6 6 21

Truevision3D SDK 5 7 4 1 17

DX Studio 3D Engine 6 8 7 4 25

The initial hope was to use the Steam Source SDK (Software Developer’s Kit) because Dan Bosscher and

Dan Ziegler both had access to the software and it was used to develop a few games they were familiar

with. Upon working with the system further, it was found to be more programming language based than

initially considered and would be much less user friendly in the environment creation stages. The

software also came with re-distribution restrictions that would have made it impossible for the project to



become a product. Since it failed to meet two of our design requirements, the Steam Source SDK was not

chosen.

The next program that was considered was the OGRE 3D (Object-oriented Graphics Rendering Engine).

This program was considered because it had a very easy to use virtual environment creator and had

favorable redistribution rules. Unfortunately, upon further use, it was discovered that the OGRE 3D

system did not have a physics engine in which to simulate the user’s presence in the virtual world.

Although a separate physics engine could have been chosen to accompany this program, the team decided

that it would be better to find a single program that encapsulated all of this functionality. For this reason,

the OGRE 3D program was not chosen.

Another program that was considered was the Cafu Engine. It was very easy to use and intuitive in its

interface, but lacking a physics engine made the Cafu Engine unable to simulate realistically. Despite its

ability to render a virtual world quite well, it could not model the physical systems required. For this

reason, the Cafu Engine was not chosen.

The Blender 3D Suite was also considered. This program had an exceptional shading capability, a full

functioned physics engine, and was open-source. Unfortunately, it is quite complicated and has a very

slow learning curve. This is the reason that the Blender 3D Suite was not chosen.

Panda3D Engine was also considered as an alternative because of its good rendering ability. It also had a

reasonable physics engine, but lacked an intuitive interface for the developer (end user) to created virtual

environments. For this reason the Panda3D Engine was not chosen.

The Unity 3 Engine was a design consideration because of its good rendering capability and included

physics engine. It failed, however, to include a simple graphical user interface. This made the program

unusable for the target customer and is the reason that the Unity 3 Engine was not chosen.

The Truevision3D SDK was another possibility because it showed the capability for a simple

development interface, requiring no previous knowledge of programming languages in order to create the

environment. It also included its own physics engine and a good rendering system. Unfortunately, the

most basic version of the software is $150. For the reason of cost, the Truevision3D SDK was not

chosen.

The final product that was chosen as a candidate was the DX Studio 3D engine. This software provided a

very user friendly interface while also meeting the rendering and physics engine requirements. It required

no previous knowledge of coding to operate and create a virtual environment. Included with the software

package are tutorials for basic and advanced users to be able to learn and do more with the software.14

The program is also free to download and distribute. Because it was compatible with all of the design

requirements, low cost, includes a physics engine, has the rendering capability, and is user friendly, the

DX Studio software was chosen.


In the virtual environment software, the input is an emulated mouse movement and possibly a roll

variable and will need to be received from the OS through the function of the input mapping program.

The output is two 320x240 stereoscopically offset quadrants in the top half of a 640x480 pixel frame.

This image will repeatedly be updated and sent to the SIM, via an NTSC cable. The software will also

have to be integrated with the other software to make a cohesive package by being included in the same

installer and being able to be run with the other components in a simple user interface.



4.2.3.6 Testing

For this software, the tests will consist of qualitatively evaluating the inputs from the input mapping by

looking for lag and error in the simulation portion.

4.3 Display System

The display system will consist of an input decoder, a processing platform, video frame buffers, two LCD

screens, and a set of optics. The design decisions and alternatives for each of these systems are itemized

below. A block diagram of the proposed display system can be seen below in Figure 6.

ALTERA CYCLONE II FPGA

HARDWARE VIDEO PROCESSING MODULES

PIXEL BUFFER A

512MB SRAM8-Bit 3 Plane 320x240

PIXEL BUFFER B

512MB SRAM8-Bit 3 Plane 320x240

VIDEO DECODERTV-VIDEO NTSC

VIDEO

PROCESSING

MODULES

TV INPUT

MODULE

RIGHT LCD24-Bit Color

320x240

LEFT LCD24-Bit Color

320x240

DIGITAL VIDEO 8-BIT

AVALON-ST

DMA MODULE

AVALON-ST

XY BITSTREAM

CLOCKED VIDEO

OUT - LEFT

CLOCKED VIDEO

OUT - RIGHT

AVALON-ST

VIDEO

24-Bit

VIDEO

24-Bit

Figure 6. Display System Block Diagram

4.3.1 3D Display Method

The method of 3D video display determines the output format from the PC, the image processing method

in the FPGA, and the format of the display. This design decision is an architectural decision as well as an

implementation decision.


The proposed project involves simulating a 3D environment for a user. To accomplish this, it is vital to

have an understanding of how people perceive depth. Depth perception is possible because of the offset

between two eyes. Each eye receives the image from a slightly different angle than that of the other eye

due to the offset between them. When the human mind receives these two images, it calculates the offset

and allows the images to be interpreted as a single image. The differences in the images get interpreted as

depth. This is why when a person closes an eye, they will lose depth perception. The mind doesn't have a

comparison image that it can use to give any meaningful sense of depth.

Based on the principle that differences between the images in each eye become interpreted as depth, one

can simulate a 3D environment if each eye is receiving a different image. This is known as stereoscopic

3D.




The alternative methods of stereoscopic 3D are side-by-side multiplexing, time-based multiplexing, and

dual video inputs. Each of these implementations involves a specific hardware setup.

4.3.1.2.1 Side-by-Side Multiplexing

Side-by-side multiplexing involves two output screens, one for each eye. This method takes one input

frame from the graphics card of the personal computer and splits it down the middle. The left side of the

frame is displayed on the left display and the right side of the frame is displayed on the right display.15

4.3.1.2.2 Time-Based Multiplexing

The time-based multiplexing method involves only one display screen. This method takes two video

inputs and combines them by filling successive frames with alternating right and left images. The screen

then outputs these successive right and left frames. The user sees the images in 3D because they are

refreshed above the persistence of vision.16

4.3.1.2.3 Dual Video Inputs

The dual video input method involves two display screens. The method takes two completely separate

outputs from two graphics cards on the personal computer and sends them directly to the two displays.17

4.3.1.3 Design Criteria

The main criteria for choosing a 3D display method are hardware cost, frame rate, and pixel density. The

hardware cost criterion is based on graphics card requirements and necessary display elements and do not

include processing. This is because it is assumed that video processing can be implemented for equal cost

in the system interface module. The frame rate is based on how fast the system can output the data to the

displays. The pixel density is based on the resolution and picture quality of the display.


The team chose side-by-side multiplexing for the 3D display method. The team chose this method

because the hardware cost only includes two display screens and because the required frame rate could be

achieved. The tradeoff was that the pixel density would have to be decreased to fit the data for two

displays in one frame. This was accepted because the small display size counteracts the loss of frame

resolution.

The method of dual inputs was eliminated from the design options because it required two graphics cards

in order to output the necessary data. Most personal computers do not include two graphics cards. The

cost of adding a second graphics card to the design would be roughly $250.18

The method of time-based multiplexing was eliminated because of frame rate issues. Our system has a

requirement of 30Hz frame rate in order to give enough time for software processing while still staying

above persistence of vision. If time-based multiplexing were implemented, it would bring the effective

frame rate of each of the two displays down to 15Hz. This would induce flicker because the 15Hz is

below the persistence of vision.



4.3.2 Video Processing Platform

The video processing platform will accept the side-by-side 3D input video stream from the PC software.

It must generate the left and right output video streams. The processor will generate the output by

cropping the left and right streams from the input and routing them to the left and right LCDs,

respectively.


The central component in the display system is the video processor. The display system requires a video

processing subsystem to correctly configure and interpret the input video signal, separate that input video

signal into the left and right signals, control the frame buffers for the LCD outputs, and drive the LCDs.


The selected alternatives for video processing can be seen in Table 9. Software processing via a RISC

processor, dedicated digital signal processing, and hardware video processing were considered to solve

the video processing problem. Another alternative not considered was a graphics processing unit (GPU).

Table 9. Video Processing Alternatives

Alternative Example Execution Method Cost

RISC Processor TI ARM AM1705 Process video in software $10 - $15

Video DSP TI TMS320C647x Process video via digital signal

processor

$180 - $300

Hardware

Architecture

Altera Cyclone II

FPGA

Hardware video processing $100 - $200

4.3.2.2.1 RISC Processor

A reduced instruction set computer (RISC) processor would solve the video processing problem through

software. An instruction routine would have to be designed that would accept incoming digitized video

data from the input decoder (see section 4.3.3 Video Input Format), and separate the video streams to

drive the outputs. The Texas Instruments ARM AM1705 contains built-in external memory interfaces for

controlling video buffers. The TI ARM AM1705 also contains built-in serial peripheral interfaces. These

interfaces could allow the processor to serve double-duty, and provide data acquisition functionality for

the head tracker in addition to video processing. The processor supports Windows Embedded CE, Linux,

and Android operating systems, among others. The TI ARM AM1705 is capable of operating at

temperatures between 0 and 90 degrees Celsius. It is available in a low profile quad flat package (LQFP),

or a ball grid array (BGA).

4.3.2.2.2 Video DSP

A video digital signal processor (DSP) would solve the video processing problem through a dedicated

signal processor. The Texas Instruments TMS320C647x digital signal processor would fit this need.

Similar to the RISC processor, the DSP would be instruction-based; however it would be optimized for

video and would contain several parallel execution cores. An example block diagram for this DSP can be

seen in



Appendix B - Texas Instruments TMS320C647x Block Diagram.

This approach would simplify the video processing design, as there would not need to be a video

processing signal flow designed on a FPGA. However, digital signal processors are expensive, and do not

offer the flexibility of being repurposed and reprogrammed. If a DSP was used for video processing, it

would necessitate the use of a small microcontroller for the head tracking data acquisition component.

This approach of using separate components for the head tracking data acquisition and display system

video processing would require more power and introduce more complexity to the video processor.

The TI TMS320C647x would operate between 0 and 100 degrees Celsius, and is available in BGA

packages.

4.3.2.2.3 Hardware Architecture

A hardware architecture would consist of a logic design, for either an application-specific integrated

circuit (ASIC) or a field programmable gate array (FPGA). Programmable logic designs are very

flexible, as they can be programmed for a variety of tasks. There is a variety of intellectual property logic

“cores” available to logic designers.19

These cores include microprocessors, memory controllers, IO

controllers, video processing, and image processing. A custom logic design for an ASIC or FPGA would

require higher initial engineering effort, but would yield fewer required parts, if multiple pieces of

functionality can be combined onto one chip. FPGA design would be considered for manufacturing

volumes under 10,000 units, and ASIC design would be considered for volumes over 10,000. This is due

to the high development cost of an ASIC.20

The Altera Cyclone II FPGA is constructed on a 90-nm process and is designed for high-volume cost-

sensitive applications. The Altera design suite features a large intellectual property catalog that would be

sufficient for the video processing problem. In addition to being highly customizable in the design phase,

a FPGA would offer the ability for a product to be re-programmed after deployment. This would allow

for updates to customer hardware via a simple re-program. Altera’s benchmarks show their FPGA

solutions to have on average 10 times the DSP processing power per dollar than the industry’s standard

digital signal processors.


The decision criteria used in selecting a video processing platform were dictated by more than just the

display system. The system interface module (SIM) which will house the video processing hardware will

also house the data acquisition hardware. Therefore, if a solution for the video processing problem exists

that can also solve the data acquisition problem without degrading the performance of either, it would be

logical to select that solution.

For the system design to be aligned with the design norm of stewardship, the component should have low

power consumption.

The solution to be selected is required to operate at room temperatures (~27 degrees Celsius). If a device

has operational capability at temperatures outside of 0 to 40 degrees Celsius, this capability will not give

that solution any more weight, as the product is not intended to be used outside of this temperature range.

The platform shall also be selected based on the configuration complexity. The system should be

complex enough to allow for a learning experience and a highly configurable and custom design, but it

shall not be so complex that the team will not be able to configure the platform in the time frame given

for the project.



A platform should be selected that is readily available for a production volume of 10,000 units per year.

Video processing performance should be considered one of the most important factors in the selection of a

solution. The video processor at a minimum must be able to process the video resolutions specified by

the input and output formats (sections 4.3.3 and Error! Reference source not found., respectively).

ore video processing capabilities that are available on the solution and more customizable and scalable

features means better solution for the long-term viability of the hardware design.


The heart of the 3D simulation helmet is the system interface module. An FPGA was selected as the

solution to the video processor problem because of the programming flexibility it offers. An FPGA

device can be configured to represent a wide range of digital systems including video processing

components and soft-core processors. This allows for the consolidation of our systems onto one chip,

decreasing system complexity and increasing the adaptability of the system post-PCB construction.

The FPGA platform has several technical and financial drawbacks. First, FPGAs are expensive even in

bulk when compared with RISC processors. They can cost an order of magnitude more. In addition to

the hardware cost, there is a generally a more advanced design cost as well. However, FPGAs offer

significant DSP processing power even in low-complexity models. Also, they offer excellent video

processing performance and customization. FPGA packages from Altera and Xilinx (the two primary

competitors in the FPGA market) offer powerful video and image processing cores that can easily be

implemented. Video processing capability was the design criteria with the highest importance.

The 10-fold increase in hardware cost over a RISC processor solution can be justified by the ease of

design. A RISC processor would appear to be the preferred option as they are available at a lower cost

than an FPGA. However, there would be a significant engineering expense in developing a software

solution for the video processing problem. The FPGA manufacturers offer video processing “cores” than

can be implemented very cost effectively.

There is no hardware cost benefit to utilizing a DSP over an FPGA, as DSP components are priced

similarly to the FPGAs that would be considered for this design. Also, if a DSP was utilized for video, a

separate microprocessor would be required for the data processing function (this is not the case with

FPGA solutions, as a soft-core processor can be included in the design.) Also, while a RISC processor

solution would have the capability of performing video processing and data acquisition duties, it is likely

that the performance of each system would suffer in this scenario, as the processor instructions would be

divided between the video processing task and the data acquisition task. In an FPGA solution, the

hardware can contain a dedicated processor and dedicated video streaming system that would not interfere

with each other.

In terms of hardware complexity, a DSP IC can be obtained as a surface mount part (SMT), the FPGA

will require ball grid array (BGA) mounting. This mounting would need to be performed by an outside

company. Power consumption is also a drawback. On average, FPGA implementations will draw 7 times

as much dynamic power than a similar integrated circuit implemented as an ASIC.21

4.3.2.5 FPGA Implementation

The FPGA will implement the video processing functionality through direct hardware. In addition, it will

contain a soft-core processor to provide the data acquisition capability (See Section 4.1.2 Data

Acquisition).



4.3.2.5.1.1 FPGA Implementation Alternatives

Solution alternatives to the FPGA Implementation problem can be seen in Table 10. Candidates from

Altera Corporation and Xilinx Incorporated were considered. Altera and Xilinx represent over 80 percent

of the FPGA market, and were considered first. Manufacturers not included in this study due to their

more specialized applications (military or other) are Achronix, Actel, Lattice Semiconductor, and

SiliconBlue Technologies.

The prices listed in Table 10 are rough estimates that include shipping. The cost is for 1 unit (Suppliers

were not found to offer economies of scale for FPGA devices). The FPGA alternatives were considered

as families; no specific product is being identified here. The selection of the final FPGA will be left to the

spring semester of the course. It does not make sense at this time to select a specific product, as the

requirements of the product may change at the micro level. The goal of this selection is to compare

manufacturers and families of FPGAs and select the best product family for the design.

Table 10. FPGA Alternatives

Family Manufacturer Cost Support & Experience

Spartan-Series Xilinx $40-$200 None, no dev. kits

Cyclone-Series Altera $80-$250 High, have dev. kits

Arria-Series Altera $200+ Medium, no dev. kits

Virtex-Series Xilinx $400+ None, no dev. kits

Stratix-Series Altera $300+ Medium, no dev. kits

4.3.2.5.1.2 Spartan Series

The Spartan series of FPGAs produced by Xilinx Incorporated is a small to medium density FPGA

package. They are available with up to 150,000 logic cells, and 180 DSP slices. Xilinx supports and

provides video input and video adjustment cores for the Spartan. The Spartan is available in several

different trims and packages, depending on the required size, application, and budget.

4.3.2.5.1.3 Cyclone Series

The Cyclone series of FPGAs is produced by Altera Corporation. The Cyclone series was created by

Altera to address high volume cost sensitive situations. There are several iterations of the Cyclone,

ranging from Cyclone I through Cyclone V. Each new version implemented higher capacity with

decreased power consumption. Altera offers a Video and Image Processing library for working with

video signals. Cyclone IV FPGAs will support up to 150,000 logic elements and approximately 600 pins.

4.3.2.5.1.4 Arria Series

The Arria series of FPGAs is also produced by Altera Corporation, and is a step-up in their lineup from

the Cyclone family in terms of capability and cost. According to Altera, the Arria series is designed to

balance a medium-level cost and power with performance. The Arria series can support up to 250,000

logic elements, and up to approximately 600 pins.

4.3.2.5.1.5 Virtex Series



The Virtex series of FPGAs is produced by Xilinx Corporation. The Virtex series was designed to be a

high-performance FPGA solution, supporting up to 2 million logic elements and 3,600 DSP slices.

Pin configurations containing up to 1,200 pins are available. According to Xilinx, the Virtex FPGA is

tailored for very advanced systems that require high performance and very high bandwidth/connectivity.

4.3.2.5.1.6 Stratix Series

The Stratix series of FPGAs is the Altera response to the Xilinx Virtex series. The Stratix series is

targeted at high end systems. The FPGAs are available with over 500,000 logic elements, 4,000 DSP

blocks, and numerous high-bandwidth IO solutions.

4.3.2.5.2 FPGA Implementation Decision Criteria

The FPGA should be selected based upon the solution that best meets the decision criteria for the video

processor (See section 4.1.1.3). The FPGA which offers the best video processing solution should be

selected if the costs are the same. If there is greater than a 10% difference in costs, the solution with the

lower cost should be selected as long as it will meet the requirements of the video processor.

Based on prototype testing of FPGA video processing, it was determined that at least 8,000 logic elements

would be required for a base design. Therefore, the selected FPGA should have between 15,000 and

30,000 logic elements (at least double) to allow for design flexibility next semester as well as future

design changes and upgrades.

The FPGA will have numerous input and output channels, as well as numerous power, clock, and ground

channels. While the exact pin count and pin layout will not be decided upon until the spring semester, a

rough estimate is outlined in Table 11 below.

Table 11. Proposed FPGA IO Pins (Minimum)

GENERAL IO PINS

LCD DRIVER PINS

MEMORY PINS

IO DEVICE SIGNAL PC IO DEVICE SIGNAL PC IO DEVICE SIGNAL PC

CLOCK CLK 1 LCD LEFT OUT RED 8 SRAM

BUFFER A ADDRESS 18

RESET RESET 1 LCD LEFT OUT GREEN 8 SRAM

BUFFER A CE 1

USER

INTERFACE 1 1 LCD LEFT OUT BLUE 8

SRAM

BUFFER A DATA 16

USER

INTERFACE 2 1 LCD LEFT OUT VS 1

SRAM

BUFFER A WRITE EN 1

TV DECODER DATA 8 LCD LEFT OUT HS 1 SRAM

BUFFER A UB 1

TV DECODER CLK 1 LCD LEFT OUT CLK 1 SRAM

BUFFER A OE 1

TV DECODER HS 1 LCD RIGHT OUT RED 8 SRAM

BUFFER A LB 1

TV DECODER VS 1 LCD RIGHT OUT GREEN 8 SRAM

BUFFER B ADDRESS 18

TV DECODER RESET 1 LCD RIGHT OUT BLUE 8 SRAM

BUFFER B CE 1

TV DECODER OVERFLOW 1 LCD RIGHT OUT VS 1 SRAM

BUFFER B DATA 16

TV DECODER I2C CLK 1 LCD RIGHT OUT HS 1 SRAM

BUFFER B WRITE EN 1

TV DECODER I2C DATA 1 LCD RIGHT OUT CLK 1 SRAM

BUFFER B UB 1

SRAM

BUFFER B OE 1

SRAM

BUFFER B LB 1

GENERAL IO

TOTAL: 19

LCD

DRIVER

TOTAL:

54 MEMORY

TOTAL: 78



TOTAL IO PIN

COUNT: 151

4.3.2.5.3 FPGA Implementation Design Selection

An Altera Cyclone FPGA platform will be used for the video processor. Based upon the requirements

laid out in the decision criteria, a Cyclone part would be more than sufficient for the design in terms of IO

capability, video processing capability, and cost. Arria and Stratix family parts are simply not required for

the level of processing done in this project, and would carry a significant cost with them. The same is

true of the Xilinx Virtex family. The cost and capabilities associated with this product are far beyond the

required scope.

A Cyclone series part will be identified in the spring semester that meets the requirements of the final

design. The part will be selected based upon pin requirements, logic element requirements, memory cell

requirements, and phase lock loop (PLL) requirements. Large scale production availability will also be

considered, as the team does not wish to select a part that is being phased out or will increase in cost

significantly over time.


The Altera Cyclone Series FPGA will function as the primary component in the video processor and the

data acquisition system. The video processor will execute the video manipulation functions in hardware

on the FPGA. The FPGA will also contain the hardware to drive the video buffer memories. The head

tracker will utilize a NIOS II soft-core processor on the FPGA to capture the current sensor status and

communicate with the computer. The details regarding the head tracker data acquisition can be found in

section 4.1.

4.3.2.7 Testing

The video processor will be tested for functionality through visual testing. It will be tested across a

variety of sources to determine if the video processor will accurately reproduce the input images on the

LCD screens. Table 12 outlines preliminary tests. The video processor will be tested for its functionality

while integrated into the rest of the display system, as it is dependent on the other display system

elements to operate.

Table 12. Video Processor Test Matrix

Test Independent Test

Variables

Dependent Test

Variables

Criterion for Success

Video Quadrant Stream

Split

Input resolution, input

device, input over scan,

input under scan, input

color format

Splitter accuracy- Did

the video processor

accurately split the

input side-by-side 3D

image to two screens?

Video output is clipped

at exactly the upper left

and right quadrants

along the vertical 320

pixel mark and the

horizontal 240 pixel

mark.

Clocked Video Output

Configuration

Accuracy and Sync

Input resolution, input



color format

LCD output accuracy -

Do the two LCD

screens clock video

accurately in all

situations?

Video updates evenly

between the two screens;

i.e. one display does not

lag the other.



Color Representation Input resolution, input



color format

LCD color accuracy –

Does the LCD

replicate the colors of

the input accurately?

The output video colors

are color-matched to the

test input pattern.

Stress Testing Time Does the video

processor accurately

drive the outputs for

long durations of

operation without

error?

The video processor will

successfully drive the

LCD for a 48 hour

period. Success is

defined as meeting all of

the above 3 criterion.

Environment Testing Ambient Temperature

and Humidity

Video Processor tests

being passed, device

temperature, device

integrity

Success is defined as all

of the video processor

system tests passing for

a period of exposure to

45 degrees Fahrenheit

for 30 minutes

Loose Cable Testing Cable Jiggles What is the effect of

connecting and

disconnecting the

input cable and/or

power cable?

The video processor will

re-sync with the video

input after being

disconnected and

reconnected. If power is

disconnected, the device

will power on reset and

resume normal

operation.

4.3.3 Video Input Format

The personal computer will be generating the 3D environment video graphics through the virtual

environment software (See Section 4.2 Software). The computer will have a graphics output that will

drive the display system. Several alternatives exist for computer graphics outputs. These options will be

analyzed and the optimum alternative will be selected for the project.


The input video stream will be the start of the dataflow into the display system. An input format for this

stream needed to be selected. The input format determines the type of video decoder needed in the

display system, as well as the type of video output the personal computer must support. It also sets the

upper limit on the quality of the output video, as the output quality cannot be better than the input quality.

The input decoder will output a digital signal to be routed into the hardware video processor discussed

above in section 0.




Table 13. Video Input Format Alternatives

Alternative Data Format Color Planes Implementation

Complexity

Widespread/

Conventional?

Cost

TV-Video Analog 1 or 2 (C, Y/C) Low Yes $3 - $15

VGA Analog 3 (RGB) Medium Yes $100 -

$150

Component Analog 3 (YCbCr) Low No $10-$50

DVI Digital 3 High No $200

HDMI Digital 3 + Audio High Yes $300

4.3.3.2.1 TV-Video

TV-Video is the analog television broadcast standard. TV-Video generally comes in two flavors: NTSC

(National Television System Committee), and PAL (Phase Alternating Line). NTSC is the North

American television broadcast standard, and PAL is the European standard. NTSC TV-Video is

composed of interlaced frames at 29.97 frames per second, and is commonly known as standard definition

in format-speak. TV-Video encodes color data as analog data based on luminance and chrominance.

Luminance carries brightness information, and chrominance carries color. Both are carried via amplitude

modulation. TV-Video requires as little as a signal line and a ground line for transmission (composite

video), but it can also include two signal lines, one for chroma and one for luma (Y/C, or S-video).

TV-Video decoders extract the video as data and stream it over a data bus digitally. Analog Devices

Incorporated, NXP Semiconductor, Texas Instruments, and ST Microelectronics make these decoders.

They are available for as little as $3.

TV-Video has a low implementation complexity, a low cost, acceptable quality, and is somewhat

widespread among personal computers.

4.3.3.2.2 VGA

VGA stands for Video Graphics Array, and has been the primary display interface in personal computers

for over a decade. The VGA signal consists of red, green, and blue color channels, a vertical sync, and a

horizontal sync. VGA maintains high quality graphics for an analog medium; although the signal will

degrade with length (VGA cable runs should not exceed 50 feet without an amplifier). The format is

capable of carrying a variety of resolutions and refresh rates.

If VGA was selected as an input format, a VGA decoder would have to be designed. This would require

the use of a high-speed analog to digital converter for each color plane: red, green, and blue. It would

also require two high-speed comparators for vertical sync and horizontal sync. This kind of high-speed

ADC would be expensive, on the order of $35.00 each. This would drive the cost of the VGA decoder

alone to over $100.00.

VGA has a higher implementation complexity, a medium cost, a high quality, and is very widespread

among personal computers.



4.3.3.2.3 Component Video

Analog component video is similar to composite TV-video, with the exception that instead of combining

all of the color information on one signal line, the red, green, and blue color planes are extracted and

transmitted on separate cables (usually RCA cables.) Analog component video is common among DVD

players and modern televisions. Component video has the capacity to transmit HD video at 720p.

Component video has a low implementation complexity, a low cost, and a high quality, but is not found in

personal computers.

4.3.3.2.4 DVI

DVI, or Digital Video Interface, can be thought of as a digital transmission of the data found in a VGA

cable. DVI operates by transmitting multiple parallel serial signals. Also like VGA, DVI supports a wide

variety of resolutions. DVI is popular on performance personal computers and performance monitors.

Unlike TV-Video and VGA, if a personal computer is not equipped with a DVI port, the hardware to

convert its output to DVI would be quite expensive (in the $100+ range.)

DVI has a high implementation complexity, a high cost, the highest display quality, and is standard

amongst performance computers, and not found amongst consumer/personal computers.

4.3.3.2.5 HDMI

HDMI, or High Definition Multimedia Interconnect, follows the same protocol as DVI. The difference

between HDMI and DVI is that HDMI is intended for the home theater market. It includes the capability

of transmitting digital audio along with video. HDMI is common on HDTVs and BluRay players.

Although it was created for home theater, an increasing number of personal computers are being released

with HDMI interfaces.

DVI has a high implementation complexity, high cost, the highest display quality. It is rapidly becoming

more included in personal computers and laptops.


The decision criteria for the input video format include price, performance, and complexity, and

availability/acceptance.

The video input format should be cost-effective. The cost of the video input format includes the price of

the video decoder and its associated hardware.

In order to appeal to customers, the input format must be popular among consumer electronic devices,

personal computers, and laptops. If the input format is not widespread, then it should be simple to

convert from the computer’s format to the input format (via the use of a common video port adapter, such

as DVI to VGA or VGA to S-Video.)

If there are multiple solutions that are both readily available, mainstream, and price competitive, the

solution with the simplest implementation will be selected, as it will reduce PCB complexity for both

design and manufacturing.




TV-Video was selected as the video input format. TV-Video is extremely cost effective, as the input

decoder can be implemented with one integrated circuit that costs less than $20. This cost is far less than

that of a VGA decoder, which is over $100. Component video could be cost effective, but component

video is not a mainstream computer graphics output.

TV-Video produces the required display performance for this project. The team tested TV-Video

decoders on development boards, and successfully processed the input video. TV-Video has a simple

implementation. It requires only one data bus from the decoder to the video processor, as the image is

Luma/Chroma formatted- this is less than one third that of VGA. VGA would require three data busses

and two sync signals.

HDMI and DVI were eliminated due to cost. Interfacing hardware that cost greater than $200 would be

beyond the scope and budget of the product, as the market strategy for this product is to undercut the

competitors. If HDMI input hardware was cheaper, it would be the logical format, as HDMI is an all-

digital format that will not lose quality over transmission.

VGA (Computer graphics) was chosen as a secondary candidate because it is the most popular connector

for the intended devices. In addition, it has full color and sync signal separation, and is extremely flexible

with operating resolutions and refresh rates. VGA could be implemented for a reasonable price.


The TV-Video input connector will be an RCA connector. This connector will be driven by the personal

computer running the virtual environment. This connector will link to a TV-Video decoder, which will

generate an 8-bit data bus, horizontal sync, vertical sync, and clock signal to send to the video processor.

4.3.3.5.1 Color Format

Just as the input video format determines the input video decoder, it also determines the initial color

format. TV-Video decoders pass digital video as 422-Chroma subsampling. 422 chroma sampling uses a

larger resolution for luma data than for chroma data, as the human eye is more sensitive to luminance.22

This 422-Chroma stream must be converted to RGB data to drive digital LCDs (this is a requirement for

small digital LCDs). The video can then be processed and buffered in different color resolutions. The

size of video data can be thought of as existing in three dimensions. There are the X and Y factors (the

pixel width and pixel height), and the resolution of the data at each pixel specified by X and Y (the Z

value). An increase in the size of the color resolution will increase the size of the video processor

components in a linear fashion.23

The color resolutions considered for this design were 16-bit RGB and 24-bit RGB. 32-bit RGB was not

considered, as few small LCDs support this color accuracy. 8-bit RGB was not considered because it

only offers 256 possible colors, and this would not provide the necessary fidelity. A visual example of the

difference between 16-bit and 24-bit RGB can be seen in Figure 7 on the following page.



Figure 7. 16-Bit and 24-Bit RGB Color Resolutions

4.3.3.5.1.1 16 Bit RGB

16-bit color is a concise color format that utilizes 5 red bits, 6 green bits, and 5 blue bits. The color green

is allocated one more bit than the red and blue because the human eye is more sensitive to green.

The 16-bit data block that will be used for each pixel will be mapped in memory either consecutively or

via X-Y coordinates. The data in the block can be seen in Table 14. The color format specified here is

commonly referred to as 16 bits per color and one color plane. 16-Bit RGB is advantageous because of

its small size per frame. However, color bands may appear blocky in 16-bit because of the small

resolution.

Table 14. 16-Bit Color Format

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

R R R R R G G G G G G B B B B B

4.3.3.5.1.2 24 Bit RGB

24-bit color, or “true color,” is a widely accepted standard for high color resolution graphics. It consists

of 8 bits each for red, green and blue. 24-bit color takes up a larger amount of space, whether it is

buffered in memory or moving around a bus. However, it is considered to be the resolution beyond which

the human eye cannot further differentiate between colors.

4.3.3.5.2 Color Format Selection

The team has done extensive testing of 16-bit and 24-bit color transmission. Operating at 24-bit color

increases the required size to buffer a frame 1.5 times. FPGA logic elements required for the video



processing cores also increases. However, the color format delivers a higher quality image at a very small

price (buffer sizes can be increased at a very low cost, and FPGA resources are also inexpensive).

Therefore, 24-bit color will be utilized in the display system.

4.3.3.6 Testing

The video input format will be tested for its functionality while integrated into the system, as it is

dependent on the other display system elements to operate. The testing for the video input format also

includes the supporting hardware that accompanies this format (TV Decoder). The test matrix can be

seen in Table 15.

Table 15. Input Format Test Matrix


Variables

Dependent

Test Variables


Video Input Frame

Perimeter

Input colors and

brightness

Video output

frame

The video input decoder did not

overscan or underscan the input video.

Video Input Refresh Motion sequences Video output The video input decoder refreshes

accurately and does not lag the input by

more than one frame (the buffer will

insert a one frame delay)

Environment

Testing

Ambient

Temperature and

Humidity

Video

Processor tests

being passed,

device

temperature,

device integrity

Success is defined as all of the video

processor system tests passing for a

period of exposure to 45 degrees

Fahrenheit for 30 minutes

Loose Cable Testing Cable Jiggles What is the

effect of

connecting and

disconnecting

the input cable

and/or power

cable?

The video processor will re-sync with

the video input after being disconnected

and reconnected. If power is

disconnected, the device will power on

reset and resume normal operation.

4.3.4 Video Buffers

In order to drive the two LCD display drivers, the system interface module will contain two video frame

buffers. Two buffers will be utilized, one for each output display, so that each streaming video path in the

Video Processor can be accessed by its own direct memory access (DMA) controller.


There are several memory types available for use as frame buffers. SRAM, SSRAM, SDRAM, and

FPGA on-chip memory are the primary alternatives. The video processor clips the left and right upper

quadrants of the total input frame (640 pixels wide by 480 pixels tall). The two output frames will be 320

pixels wide by 240 pixels wide.




Table 16. Frame Buffer Alternatives

Alternative Access Speed Complex Price Available Size Power

Consumption

Example

SRAM 10ns – 45ns Low $1.00 -

$6.00

4kB – 64MB Low, higher

dynamic

ISSI

IS42S324

00E

SSRAM 3ns – 15ns, use

20ns

Low $6.00 -

$12.00

2MB – 64MB Low, higher

dynamic

ISSI

IS61C256

AL

SDRAM 6ns-10ns, use

20ns

High $3.00 -

$15.00

16MB – 1GB High ISSI

IS612LPS

FPGA On-

Chip RAM

20ns Low Included

in FPGA

1k – 16k Low, higher

dynamic

Cyclone

Memory

Cell

4.3.4.2.1 SRAM

Static random access memory modules allow for quick asynchronous access times and general simplicity.

They are also the cheapest form of memory. They carry the drawback of being generally limited in

capacity. Static memory cells retain their latched values as long as the module is powered, and do not

require any refreshing. They have very low power usage unless they are being frequently switched.

4.3.4.2.2 SSRAM

Synchronous static random access memory modules allow for fast memory access times (less than 10 ns).

This ability comes from their synchronous nature, as the outputs are clocked-in registers. They are

generally limited in capacity to below 64MB. They have very low power usage unless they are being

frequently switched.

4.3.4.2.3 SDRAM

Synchronous dynamic random access memory modules offer large memory sizes at a low cost. They

carry the drawback of requiring a dynamic refresh. The ISSI (Integrated Silicon Solution, Inc.) SDRAM

module analyzed above requires a refresh 4000 times every 64ms. This refresh causes SDRAM modules

to draw higher static power than SRAM modules.

4.3.4.2.4 FPGA On-Chip RAM

Altera and Xilinx FPGA modules offer on-chip random access memory and read-only memory. These

components can be mapped to soft-core processors or used for other purposes. While they are extremely

convenient because they do not require any support hardware outside of the FPGA, they are almost

always limited to low sizes (less than 32k) in small FPGAs.


The first criterion in buffer memory selection is buffer size. The memory alternative must support the

required size. The buffer must be large enough to completely buffer one frame of video. The output



resolution for a given individual output feed is 320 pixels wide by 240 pixels tall. At a color depth of 24

bits, the required size per frame can be calculated as follows.

𝐵𝑈𝐹𝐹𝑆𝐼𝑍𝐸𝑚𝑖𝑛 = 𝑝𝑖𝑥𝑒𝑙𝑟𝑜𝑤𝑠 ∗ 𝑝𝑖𝑥𝑒𝑙𝑐𝑜𝑙𝑢𝑚𝑛𝑠 ∗ 𝑏𝑖𝑡𝑠 𝑝𝑒𝑟 𝑝𝑖𝑥𝑒𝑙 = 240 ∗ 320 ∗ 24 = 1843200 bits = 230.4 kB

The memory technology selected should have a response time that is sufficient for the bandwidth

required. If one frame consumes 230.4 kB, and the video is set at a refresh rate of 29.97 Hz (NTSC given

standard), the required data bandwidth can be calculated as seen below.

𝐵𝑈𝐹𝐹𝐵𝐴𝑁𝐷𝑊𝐼𝐷𝑇𝐻 = 𝐵𝑈𝐹𝐹𝑆𝐼𝑍𝐸𝑚𝑖𝑛 ∗ 𝑃𝐼𝑋𝐸𝐿𝐶𝐿𝑂𝐶𝐾 = 1843200 ∗ 29.97 = 55240704 = 56𝑀𝑏𝑝𝑠

While it is a lesser concern than buffer size and bandwidth, a memory technology with lower power

consumption should be considered. As one of the design norms of this project is stewardship, lowering

the power consumption of the device is not only better for the user in terms of operating cost, but

environmentally responsible as well.

All other characteristics being equal, the memory selected should be as cost effective and as simple as

possible.


Static random access memory (SRAM) was selected as the memory of choice for the video frame buffers.

In the sizes that are required, a simple SRAM IC will be more cost effective in terms of price and

footprint than either synchronous static random access memory (SSRAM) or synchronous dynamic

random access memory (SDRAM). SRAM would not be clock-synched, whereas SSRAM latches the

memory data flow to a clock edge. This functionality is not required for a video frame buffer, and as such

would only include added cost and complexity.

The control complexity surrounding SDRAM and the associated speed loss that comes with that

complexity makes SDRAM unattractive. Also, the higher power demands of SDRAM (compared with

SRAM or SSRAM), eliminated SDRAM from being a viable alternative for the frame buffer memory.

It should also be noted that all of the memory systems supported the bandwidth requirement. All memory

technologies had refresh rates below 20ns, the system clock period. Therefore, if a 16-bit data field is

assumed, a DMA module could access data at 800Mbps if it read a memory value every clock tick.


The pixel buffer memory is part of the display system. The memory modules will be situated close to the

FPGA on the SIM printed circuit board so as to eliminate any possible trace capacitances or clock skew.

The memory modules will be linked to the video processor through a direct memory access (DMA)

module.

4.3.4.6 Testing

The video buffer memory will be tested as an integrated component of the display system. The memory

will be directly mapped to the video processing cores on the FPGA and will not be accessed by software.

Therefore, the testing will be concurrent with the video processor testing. The test matrix for the video

buffer memory can be seen in Table 17.



Table 17. Video Buffer Memory Test Matrix


Variables

Dependent

Test Variables


Video Input Frame

Perimeter

Input colors and

brightness

Video output

frame

The video input decoder did not

overscan or underscan the input video.

Stress Testing Time Does the buffer

SRAM operate

without issue

over time?

The buffer SRAM will successfully

interface with the video processor for a

48 hour period. Success is declared if

the video processor passes all of its

system tests.

Environment

Testing

Ambient

Temperature and

Humidity

Video

Processor tests

being passed,

device

temperature,

device integrity






effect of

connecting and

disconnecting

the input cable

and/or power

cable?

The buffer SRAM will reset on a power

loss, and will immediately regain

functionality upon power-up.

4.3.5 Video Output Format (to the LCDs)

The output video will drive the LCDs from the FPGA. The LCDs will be thin-film-transistor (TFT)

displays with a pixel resolution of 320 pixels tall by 240 pixels wide. This resolution is extremely

common among LCD displays, allowing displays from several manufacturers such as Newhaven Display

International, Toshiba, and Parallax Incorporated to be considered.


The team must select an output format that can interface to a LCD screen over a digital connection. This

output will, by default, need to be able to interface between the selected TFT LCDs and the video

processor.


One output display format alternative is an 8-bit wide data bus that will carry all color data. This offers a

low number of required signals, but requires a higher clock rate.

Another output display format alternative is a 24-bit wide data bus that will carry the color data across

three individual 8-bit busses. This allows for a lower clock rate, but increases the number of required

signals threefold over a single 8-bit data bus.




The desired output format will need to fit within the FPGA limitations. This means that there must be

enough available pins to drive the device. In addition, the FPGA video processing cores must be able to

interface to the device.


A 24-bit data bus was selected as the output display format because of its simple integration with the

Altera video processing cores. In addition, the clock rate must be kept as low as possible. Therefore the

team decided that each color channel will be clocked at the same time to keep the display clock rate

down. The display clock rate is a function of pixel rows, pixel columns, and color plane transmission

method.


This output format will require that the selected TFT LCD displays transmit color planes in parallel. The

output will be driven by a clocked video output on the FPGA for each LCD. This will take into

consideration the advanced configuration requirements of the LCDs such as front porch, back porch,

display period, pulse width, setup time, and hold time. The particular LCD to be used in the prototype

will be identified in the spring semester.

4.3.5.6 Testing

The video output will be tested as a part of the display system, as it requires a driver and source to be

tested. The test matrix can be seen in Table 18.

Table 18. Output Video Test Matrix


Variables

Dependent

Test Variables


Stress Testing Time Do the LCD

displays

operate without

issue over

time?

The LCD displays will successfully

interface with the video processor and

display for a 48 hour period. Success is

declared if the video processor passes

all of its system tests.

Environment

Testing

Ambient

Temperature and

Humidity

Video

Processor tests

being passed,

device

temperature,

device integrity






effect of

connecting and

disconnecting

the input cable

and/or power

cable?

The LCD displays will reset on a power

loss, and will regain functionality upon

power-up.



5 Physical System Specifications

The physical design of the headgear will consist of three main parts: the helmet, the System Interconnect

Module (SIM) enclosure, and the wiring connections.

5.1 Helmet

For the prototype, a helmet will be purchased to mount the rest of the system. The specifications for the

helmet are not yet clearly defined. The team will provide weight and LCD mounting structure

specifications when the physical system is designed next spring. The stereoscopic LCD array and the

lenses will be mounted on the visor so that they hang down in front of the user's eyes. On either side of

the helmet, stretching from the front to the LCDs will be a form of light shielding material. This material

will shield against outside light, creating a more immersive experience for the user and making it easier to

focus on the display. The design will also provide a barrier between the two LCDs to increase the visual

isolation of the LCD screens.

For a production design, the helmet would be manufactured to be a single piece, with everything as a part

of the helmet. All electrical components would be encased within the helmet, as would the wiring to the

display. The LCD array and lenses would be mounted on a visor that would come down to the level of the

user's nose. The visor would also wrap around, preventing light from entering the helmet.

5.2 System Interface Module (SIM) Enclosure

The SIM is only significant in the prototype design. The components included in the SIM will be

enclosed inside the unit as part of the production design. The enclosure will contain the majority of the

electrical hardware for our project. This includes the data acquisition and video processing circuits. The

enclosure will sit close to its connection to the PC and will have a long tether connection to the helmet

portion of the design. The enclosure will be made out of plastic and will be a rectangular prism in shape.

It will be as large as is necessary to hold the PCB for the data acquisition and video processing circuits

and the power system.

5.3 Wiring and Interconnection

All of the wiring will be connected to the enclosure. The helmet will be tethered to the SIM by three

cables. The first of these cables would be to power the helmet, while the remaining two would convey

data from the accelerometer and gyroscope sensors continuously. The SIM will be tethered to the PC by

two cables and to a wall outlet with one cable. The cable to the wall outlet will be the power supply for

the unit. The two cables from the SIM to the PC will be one RS232 serial to USB cable for the motion

tracker data and one TV-Video to NTSC cable for sending the virtual world picture to the video

processing unit. Another connection is required to connect the video processing unit to the LCD array. See

section 4.1.4 for more details on the formatting for this connection.

5.4 Optics

Existing products on the marketplace that involve displays at close proximity to the eye utilize lenses to

focus the retina in the user’s eye to the screen.

A concern with the simulation helmet design is that the LCD array will be too close for the human eye to

focus on unaided. The lens of the human eye is a converging lens, allowing images to focus on the retina

so that they can be seen.24

As objects get closer to a converging lens (as the display in our design would),



the resulting image will converge farther from the lens behind the retina. The implication of this is that the

image will appear to be out of focus. In order to fix this, the lens would have to be modified to cause the

image to converge closer to the lens (bringing the image back to the retina). This can be achieved by

adding a convex lens between the eye and the LCD array. The extra lens will cause the image to begin

converging before it hits the eye. This will bring the point of convergence forward, back onto the retina,

resulting in a focused image for objects closer to the eye.

6 System Integration Testing

System testing will cover interconnect testing, latency testing, throughput testing, and any tests that apply

to the system as a whole. The testing will verify that all of the possible inputs are correctly interpreted

and handled by the system. If a user moves his or her head, the video should respond in an appropriate

manner.

6.1 Video Delay Testing

A long delay between motion input and video response can cause motion sickness. We will want to verify

that video responds quickly enough to avoid motion sickness. According to Lag in Multiprocessor Virtual

Reality by Matthias M. Wloka, if lag is greater than 300 milliseconds, users lose the feeling of immersion

because they notice the time difference between their movements and the expected movement.25

We will

need to test on a variety of users to account for variations in sensitivity.

6.2 Motion Sensitivity Testing

We want the video to respond on an appropriate scale to movements. If the system is too sensitive, small

motions will be picked up by the system causing a jittery video. If the system is not sensitive enough,

larger motions would be required to incite a response from the system. Either case would create a

negative user experience. To test for minimum sensitivity, the position of the avatar can be related to the

position of the user. The angular displacement of the avatar’s field of view should be the same as the

angular displacement of the user’s field of view. For example, if the user turns their head 90 degrees to

the right, the avatar should turn 90 degrees to the right.

6.3 Power Consumption Testing

We want to be certain that all components of our product will receive adequate power at all times. We

want to avoid current draw fluctuation that could damage the components of the system, either in over

current or under current situations. To test for these conditions we will use a digital multimeter to

measure the voltage and various test points.

7 Business Plan

7.1 Vision and Mission Statement

SimEscape’s vision is to build its product efficiently and decrease production cost. We want to keep

innovation as one of the driving factors to stay competitive in the market. This means that our engineers

will always be involved in ongoing research and development. The research and development will be

customer-driven and technology-rooted.



SimEscape values trust, integrity, and stewardship. The company wants the customers to trust that the

product can accurately represent a virtual environment. SimEscape also wants to accomplish this by

providing customers with high quality products. The company wants to show integrity by being

responsible for any flaws, which means providing warranty and customer support.

7.2 Industry Profile and Overview

The virtual reality industry has existed since the 1960s, but the greatest amount of development in the

industry has happened in the past 20 years. These developments have increased not only the quality of

virtual reality, but also the unit size. The industry has traditionally defined quality in terms of ergonomics,

field of view, resolution, level of immersion, and functionality. These are the aspects of the product that

the company will have to focus on in order to be competitive in this industry.

7.2.1 Major Customer Groups

The major customer groups for virtual reality HMDs are academic research, military training, emergency

response training, aviation training, architectural and engineering design, medical research and training,

and consumer media. Each of these customer groups presents its own expectations and restrictions. For

this reason, SimEscape must decide which groups to target as customers.

7.2.1.1 Academic Research

Academic research groups would be able to use the product for 3D modeling for applications such as

modeling proteins and molecules. This market does not contain a large number of customers. However,

these customers would be looking for higher quality, and most would have more funding to pay for the

higher quality (although this would vary based on the institution).

7.2.1.2 Military Training

The military would be able to use the product for training simulations. Military groups would have large

funds at their disposal to purchase the product. However, this group would present high demands on

quality, and have more restrictions than other customer groups would. It would be fairly easy to do

business with the US military, but the company might run into regulation issues if it tries to do business

with other countries.

7.2.1.3 Emergency Response Training

Emergency response groups would also use the product for training. These groups would include police,

firefighters, search and rescue, and hazardous materials response teams. There are many customers in this

group, but they would not have significant spending power. These groups are funded by local

governments, and generally have tighter budgets. However, the federal government could provide grants

to these organizations to purchase the product.

7.2.1.4 Aviation Training

Airline companies and the US Air Force would be able to use the product for flight training. Although

there are not that many customers in this category, they would have the resources to purchase a high-end

product. They would also want a faster product with no noticeable lag. Dealings with the USAF would

also mean providing for regulations for military specification.



7.2.1.5 Architectural and Engineering Design

There would be a limited number of architecture and engineering firms that would be able to use the

product for 3D design modeling. This group would be relatively small, and would desire a high precision

product. Also, these companies might not have the funds of other groups, and would most likely not be as

willing to pay a high price for the product.

7.2.1.6 Medical Research and Training

Hospitals would probably be interested in virtual reality for training and for 3D imaging of the body (for

diagnosis and medical examination). They would have mid-range funds, but would need to see a

significant improvement over current imaging techniques in order to make the move to the product. If the

product would be used for viewing images of inside the body the product would have to be very precise in

its measurement of head movements. There would also have to be a high level of display detail. This

market is fairly large, but will not be willing to spend as much.

7.2.1.7 Consumer Media

The product would also be able to be used for consumer media. This is mainly applicable to video games.

Although movies could be viewed on the product, they are more of a social event and hence less of an

application. Video game users would want a low cost product, and the quality would have to be

comparable to a standard display. There are a large number of potential users in this product, but many of

them would not be motivated to buy.

7.2.2 Regulations and Restrictions

For customer groups that would use the product for academic, architectural and engineering design, or

personal entertainment functionality, there are no known regulations for this sort of device. The medical

field has guidelines set up by the World Health Organization (WHO) for getting medical devices onto the

market. In the US these include getting either an approval letter (PMA) or marketing clearance (510K) to

clear the product for the market, as well registration with the medical device establishment. Additionally,

the US military has a number of standards that would apply to virtual reality systems. These include:

MIL-STD-202 regarding test methods for electrical parts, MIL-STD-461 regarding the control of

electromagnetic interference of equipment, MIL-STD-498 regarding software development, MIL-STD-

499 regarding systems engineering, MIL-STD-883 regarding test methods for microelectronics, and MIL-

PRF-38535 regarding integrated circuit manufacturing26

. This is not an exhaustive list of regulations, but

it provides a framework for the type of regulations that will be placed on the product.

7.2.3 Significant Trends

The current virtual reality market is moving away from consumer media and into high end simulation for

design and training. This suggests that, although the consumer media market appears large, the number of

people who would be willing to purchase it for personal use is lower than expected. However, users who

would use the product for high end simulation seem to be willing to pay high prices for similar devices,

so many competing companies are changing their focus to target these customers.

7.2.4 Growth Rate

The virtual reality and simulation market is growing at a significant rate, especially for higher cost

applications. A June 2004 report noted that anti-terrorism spending in this market increased by 75% from



October 2002. 27

This report is a little dated, but more recent reports are showing continued growth in

other areas as well. An article from this February shows that the market for health care applications in the

US between 2006 and 2010 has grown annually by more than 10%. Researchers are expecting even

greater growth in this area through the year 2015.28

Additionally, the oil and gas market for virtual reality

is expected to grow over the next ten years as well.29

7.2.5 Barriers to Entry

There are a number of barriers preventing new companies from entering this market. Since virtual reality

products run on the expensive side, economies of scale are important to lower cost per unit. The high

technology nature of the field increases the amount of design work required for the industry, preventing

new companies from entering. New companies will also be relatively unknown, and would take some

time to gain some credibility among consumers. Finally, there is a large start-up cost that would need to

be overcome to enter the market.

7.2.6 Key Success Factors in Industry

The key to success in the virtual reality industry is the ability to move in to high quality markets. This

means giving up low cost to offer the best available technology. It is understood that virtual reality for

personal use is not currently considered a profitable market, so larger entities such as the military and tech

corporations are targeted as the key to success. These groups will have higher requirements for quality,

but they will also be able to pay for the quality improvements.

7.2.7 Outlook for the Future

As time passes, this industry will offer more opportunities. Cost for parts will decrease, making lower

cost markets more feasible. Additionally, the technology in this field will continue to develop, allowing

customers to update to the most cutting edge systems.

7.3 Business Strategy

The desired image of the company is to create a quality product at a low cost while continuing to

innovate. The company desires to start as a lower cost alternative in the market and steadily increase

quality as market share is gained.

7.3.1 Company Goals and Objectives

The operational goal of the company is to design a product using the latest available technology. The

product should be designed in such a way to balance quality and low cost.

The financial goal of the company is to use the first generation design to make enough profit to repay

startup loan debt as well as reinvest in the company for future growth. The main focus will be to repay

debt in order to lower risk of the LLC’s members in the case of economic instability.

7.3.2 SWOT Analysis

SWOT analysis is an important step in determining how a new company fits into an already defined

market. By assessing the company’s strengths, SimEscape will know what features to focus on

marketing. By assessing its weaknesses, the company will know where not to compete with other



companies. Identifying opportunities defines SimEscape’s potential growth options and identifying

threats helps the company manage and mitigate risk.

7.3.2.1 Strengths

One of the main strengths of the company is that the product will be high quality while maintaining a low

cost. This creates a reputation in the marketplace of a well-engineered product. The product will also be

easy to set up and use, therefore reducing the complexities on the client side. Another strength is that the

company will be small, making it easier to adapt to the changes in the market.

7.3.2.2 Weaknesses

There are several weaknesses that must be addressed in marketing the product. One weakness is the

limited target market. Therefore, the company must aggressively market the product to become well

known and trusted. Another weakness is that the profit margin for the company is low, due to the low

selling cost. To overcome this, the product will continually be updated with low cost components.

7.3.2.3 Opportunities

The main opportunity of the company is growth in the virtual reality market for high end simulation and

training. As the technology becomes widely accepted, the number of companies looking for virtual reality

will increase. To take advantage of this opportunity, the company will aggressively promote the product.

7.3.2.4 Threats

The threat to the company is other similar companies lowering their cost, therefore reducing the profit

margin and forcing the company to sell at a lower cost. Another threat is other startup companies with

similar products. In order to reduce this threat, the company will sell the product as low as possible while

keeping a decent profit margin, therefore reducing the opportunity for other companies.

7.3.3 Competitive Strategy

The company is looking to create its own niche in the market, covering a price range that is not currently

covered by other companies. The main focus is cost leadership for existing quality standards. The

company is not looking to compete with the highest-quality systems already on the market, but is looking

to have comparable quality to mid-range competing products. However, the company is looking to

undercut competitor prices and offer the best value product on the market.

The focus of the company is to target specific markets. Rather than create mainstream products that are

compatible for many applications, SimEscape will design products that are specific for certain simulation

applications.

7.4 Marketing Strategy

The market strategy analyzes the target market, market size, market trends, advertising, and price. A brief

description of the customer motivation to purchase the product is included. Distribution strategy is also

outlined.



7.4.1 Target Market

SimEscape’s target market is the group of customers that require the use of virtual environments for the

use of training or education. SimEscape also aims to sell to companies that use 3D imaging for

development or design such as medical research companies or architecture firms.

The company’s product is not limited by gender, race, status, or location. The SimEscape product will,

however, be designed for adult users. Since SimEscape will mainly be selling to companies rather than

specific individuals, it is up to the customers to decide which of their employees, personnel, students, or

workers will be using the product.

The product’s end users may include military personnel, pilots, architects, doctors, emergency response

teams, and professors. The levels of technical understanding of the product will vary greatly in the

different user groups, so the product will have to appeal on different aspects to be viable in different

markets.

7.4.2 Customers' Motivation to Buy

The customer will buy our product in order to prepare users for various scenarios that they may encounter.

If the customer’s employees or personnel have been trained through realistic training exercises, their

response to situations will be better that that of untrained employees. This increase in situational

knowledge can reduce company risk, increase workplace safety, save money, or even save lives.

7.4.3 Market Size and Trends

Since SimEscape has multiple target markets, there will be variation in the market size depending on the

sector of the economy. Overall, the trend towards simulation technology is rising as companies

acknowledge the benefits it provides.

The following excerpt explains the situation of the Healthcare Virtual Reality market.

According to the report, in 2010, the U.S. market for VR applications in healthcare reached

approximately $670 million in sales. The market enjoyed a compound annual growth rate

(CAGR) of over 10% during the 2006-2010 period. Kalorama Information projects market

growth to continue at a greater rate through 2015 as equipment and technology spending

recovers among U.S. healthcare service providers.30

The oil and gas virtual reality simulation market in 2011 is worth $2.24 billion.31

Also, according to

Aviation today, the market size for pilot training in 2008 was $10 billion.32

All of these markets are

increasing. Military market statistics were not available for public access, but can be reasonably assumed

to be at least comparable to the other markets.

7.4.4 Advertising and promotion

Since the target market of the company does not include consumers, advertising strategies using popular

media such as TV advertisements or social media advertisements will not be appropriate. Instead, the

company will use publications or journals to notify customers about the product. Professional association

publications for the development communities such as IEEE or American Architectural Foundation will

inform the end users about the technology that our company provides. This also applies to the Medical



Healthcare companies and the other markets which would mean advertising in publications for healthcare

professionals. Advertising using newspapers and magazines would be the most appropriate form of

promotion.

SimEscape will have a website to promote the technology developed by the company. There will be a

demonstration page to show the applications for the product. Other ways to utilize the Internet include

using Google advertisements and posting video demonstrations accessible by the public. Another way to

inform companies of our product would be to start a marketing department in the company. This can be

combined with the sales department. However, since the startup company is small, the budget for sales

and marketing cost will be small relative to the cost of design and production. The best way to promote

our product is by getting positive reviews. As the company’s product gets good reviews, customers will

spread the product by word-of-mouth as more companies use our product.

7.4.5 Promotion Costs

Since the majority of the advertisement would rely on publications and magazines, a graphic design

contract would be a good investment. The cost of posting an advertisement in magazines or newspapers

varies with the size of the advertisement but will be more than a $1000 per issue. A website developer will

not be necessary since the team members have experience with designing a website. The cost of owning a

domain name can vary between $10 and $20 per year. Also, in the initial stages of the company, a

marketing department might not be feasible.

7.4.6 Pricing

SimEscape wants to be portrayed as a company that values trust, integrity, and stewardship. We also want

to show the customers and competitors that we can build a high quality product and sell it for a reasonable

price while having a good profit margin to be sustainable. Compared to other competitors, our price is

about 10% of our closest competitor’s price.

7.4.6.1 Discount Policy

Discounts offered will depend on the customer or the company’s earnings. The company will offer

discounts of up to 5% to customers that order in high volume, that is, over 100 units. Also, discounts will

be offered to customers who present a strong commitment to the company by continuing to buy and use

our product and communicating issues clearly. We want to maintain a good relationship with customers.

The company will also offer discounts when there is excess inventory.

7.4.6.2 Projected Gross Profit Margin

The projected gross profit margins for year one and year two are estimated at 45%. For year three, the

gross profit will increase to 46%.

7.4.7 Distribution Strategy

SimEscape will sell products mainly through the company’s online website. There will be an online store

page that shows the company’s products and possible optional accessories. There will also be a page that

describes the features of specific products and reviews. The company may also distribute products

through online retailers such as Amazon or make create limited listings on eBay stores.

The company will keep the inventory in a warehouse. The warehouse will be located near the western

coast of North America due to the fact that manufacturing will ship the finished products from locations



in Asia. Flextronics is headquartered in Singapore and has the majority of their manufacturing facilities

near their headquarters.

7.5 Competitor Analysis

The competition for this kind of head mounted display (HMD) product is varied and can be determined

by starting with manufacturers of HMDs and narrowing down by functionality. Then, the actual

competitors in the target market can be compared in terms of cost and quality. Our research of

competition in any market of HMD and simulation technology yielded the following list of companies: IO

Display, Virtual Research, Liteye HMD, Cybermind, Rockwell Optronics, Vuzix, Trivisio, NVIS, eMagin,

and Sensics. Our search also identified potential competition from Gentex Corporation.

Each of these competitors has different target markets and therefore different tradeoffs between the

factors of functionality, quality, and price. These tradeoffs define which of these competitors are directly

competing with our company. The tradeoffs also show their strengths and weaknesses in their business

model for their product. By analyzing these strengths and weaknesses our team can then devise a strategy

for market entry and market share acquisition.

A list of possible competitors based on companies that make HMD products is shown in Table 19 below.

A company can only make a product that is a viable competitor if it fulfills all of the required

functionality. Companies that do not have any of the functionality required make augmented reality (AR)

systems instead of virtual reality (VR) systems. AR systems display information onto see through

surfaces during real situations, and therefore cannot create immersive simulation environments for

training. Companies that are actual competitors are highlighted in blue. Companies that are future

potential competitors are highlighted in gray.

Table 19. Comparison of Competitor Product Functionality

Virtual

Reality

3-D Display Head

Tracking

Immersive

IO Display33

X X

Virtual Research X X X

Liteye HMD34

Cybermind X X X

Rockwell

Optronics

X X X X

Vuzix X X X

Trivisio X X X X

NVIS X X X X

eMagin X X X

Sensics X X X X

Gentex X

Fifth Dimension

Technologies

X X X X

7.5.1 Existing Competitors

Several competitors exist to the SimEscape product. This section outlines the competitors that are in the

target market currently.



7.5.1.1 Rockwell Optronics

Rockwell Optronics (formerly Kaiser Opto-Electronics) has HMD technology with the necessary

functionality to compete with our product. It does, however, require that head tracking hardware is sold

separately, increasing cost for the modularity aspect. The cost of the system is $27,500 per unit plus

another $500 for the head tracker. Our aim is to severely undercut this price while providing comparable

quality.35

7.5.1.2 Fifth Dimension Technologies

Fifth Dimension Technologies has the HMD technology to make a competitive product to the proposed

design. However, like many competitors, the cost is quite high. The base model without motion tracking

is $10,000, and including the motion tracking it is $10,700.36

Our goal is to provide a comparable or

better performance while undercutting their price.

7.5.1.3 Trivisio

Trivisio has the HMD technology to make a competitive product to our design. Trivisio has the potential

to be one of our biggest competitors because it has near the quality we propose and the competitive price

of $5,230 per unit. This price is without a motion tracking unit, but with the motion tracker it is still only

$5,750. We hope to still be able to provide the same or higher quality in our product while undercutting

this price by a significant amount.

7.5.1.4 NVIS

NVIS has a very high quality product with very good specifications. It will be higher quality than our

product, but comes at a very high cost. The base unit includes high resolution display, but starts at

$34,300. It also does not include motion tracking. The higher end models reach $44,500 and include

motion tracking. We hope to enter the NVIS market share by severely undercutting their price and not

trying to reach their level of quality.

7.5.1.5 Sensics

Sensics has a very high quality HMD product with very good specifications. Our goal is to not compete

on quality, but on price. The base unit includes high resolution display, motion tracking, and wireless

communication, but starts at $24,000. The higher end models reach $39,000 and include a much wider

field of vision. We hope to enter the Sensics market share by severely undercutting their price and not

trying to reach their level of quality in the same way we undercut NVIS.37

7.5.2 Potential Competitors

Potential competitors include the competitors that have either the capability to enter the market, the

interest to enter the market, or both.

7.5.2.1 Gentex

Gentex is considered a potential competitor because they recently acquired Intersense, a motion tracking

technologies firm, because they already make AR helmets for military, non-training use, and because it is

a large company with lots of engineering expertise. The reason we are not worried that Gentex will make



the jump into training and simulation is because it is a comparatively small market and they are probably

not interested.

7.5.2.2 Virtual Research

Virtual Research is considered a potential competitor because it needs only to implement a head tracking

unit.38

The reason we are not worried about this potential competitor is because its base price without

tracking systems is $15,900 and will only increase with added complexity.39

7.5.2.3 Cybermind

Cybermind is considered a potential competitor because it needs only to implement a head tracking unit.

The reason we are not worried about this potential competitor is because its base price without tracking

systems is $11,930 and will only increase with added complexity.40

7.5.2.4 eMagin

The company eMagin is considered a potential competitor because it has most of the necessary

technology to become a real competitor. The current product is a media and entertainment product that

costs $1,799 per unit. The company eMagin, unlike other potential competitors, would need to redesign

their system to a much higher quality standard in order to cater to the needs of the simulation target

market. This would be a redesign for a more immersive interface as well and creating a product with

higher quality components. This would definitely increase cost to similar costs to the market standard for

this quality.41

7.5.2.5 Vuzix

The company Vuzix is considered a potential competitor because it has a similar concept. Vuzix,

however, uses a lower quality approach that targets the consumer market looking to sell a cheaper product

to a larger audience. The device underprices the SimEscape product at $300, but it also does not provide

the immersive experience that our product will provide. The Vuzix Corporation could develop a product

at the level of the SimEscape product, but it would take time and money to produce this design and a

price increase to sell it.

7.6 Financial Forecasts

The financial forecast for SimEscape LLC is detailed in the Projected Financials in Appendix C.

7.6.1 Financial Forecast Description

This pro-forma statement of income and statement of cash flows outlines the predicted company financial

plan for the first 3 years including break even analysis, ratio analysis, debt repayment schedule, and

possible exit strategy.

7.6.2 Key Assumptions

Our financial forecast made several key assumptions about the way our business would function and the

financial model proposed. The first assumption was that the company would undergo constant growth.

For newly started small company, growth is usually very fast in the first few years and careful

management of that growth can keep it from getting out of control. The assumed growth rate was 20%

annually, a typical growth rate for small businesses in their first few years. The next assumptions made



were that sales and cost would be distributed evenly over each year. These assumptions were made to

simplify calculations. Another simplifying assumption was that inventory would be sold in the year that it

was produced. Also assumed was that contract manufacturing would be in fixed unit volume blocks of

10,000 per year. This is an estimate that fits the projected sales volume the company expects and would

incur a slightly higher per unit rate from the manufacturer for the low volume. This is included in the

company’s estimate of per unit cost. The next big assumption is that the company will be able to sell its

entire inventory yearly. If this is not possible, the break even analysis discusses how many units need to

be sold for profitability on a yearly basis. The next major assumption was that the members of the

company will be able to procure $900,000 capital investment and a startup loan of $3,506,000. This

assumption is based off of the ability to keep that investment in collateral in the form of finished product

from the contract manufacturer.

7.6.3 Financial Statements

The following financial statements show the feasibility of the company as a whole. This includes the

projected incomes, yearly balances, and cash flow statements.

7.6.3.1 Income Statement

The key points of the income statement are the price point, 3 year IRR, and net incomes over the first 3

years. The most profitable price point was calculated to be $500 per unit based on possible volume sold

and profit margins per unit. At this price point of $500 per unit, the 3 year IRR is 48%, 77% if we

successfully sell the company for 4x EBIDA at the end of year 3. Both of these measures are after tax.

The resulting net income after tax in year 1 is $286,000. Year 2 results in net income of $481,000 and

year 3 yields $700,000. More detailed information can be found in the projected financials in Appendix

C.

7.6.3.2 Balance Sheet

A balance sheet is not included in the financial analysis because the company is assuming no credit sales

or purchases. In this business model the company assets can simply be reduced to available cash and the

value of the investment in injection molds for the plastic parts of the design. Inventory on hand would

not be included because of the assumption that all inventory would be sold by year’s end. The company

debt is simply the bank debt at a 10% interest rate. The equity is only the invested capital from day 1, that

is, the original $900,000 invested in the company.

7.6.3.3 Cash Flow Statement

The most important points of the cash flow statement are the reinvestment plan and the plan for the excess

profits. The company has decided to only reinvest what is needed for working capital and to use the

excess profits to pay off company bank debt. This strategy was chosen because of the high level of initial

debt. More detailed information about company cash flows can be found in the projected financials in

Appendix C.

7.6.4 Break-Even Analysis

The break-even analysis is detailed in the projected financials in Appendix C. However, these numbers do

not detail calculations of the break-even price point through adjusting price point to the point of no net

income after tax in year 1. This break-even price point was calculated to be $455 per unit. At the ideal

price point of $500 per unit, the break-even unit sales volume is 8,731 of the 10,000 units produced.



7.6.5 Ratio Analysis

The key ratios for the financial projections of SimEscape LLC show the viability and projected

profitability of the company as a whole. The calculated gross margin of revenue is 46% each year. This

is a metric of the company’s profitability because significant revenue is made above the covering of cost.

The profit margin in year 1 is 6% and increases to 8% in year 2 and 9% in year 3. This trend of growth

indicates the company’s ability to pay off bank debt, invest in future growth, and return capital to the

owners. The net asset turnover in year 1 is 1.13 and increases to 1.48 in year 2 and 2.02 in year 3. This

number is a metric of the number of times the company can sell the company’s assets worth of inventory

in a year. These values are increasing, suggesting increasingly efficient inventory management. Finally,

the debt to equity ratio is 3.90 in year 1, 3.50 in year 2, and 2.96 in year 3. Our plan is to have the debt

reduced as quickly as possible to reduce the company’s risk in the debt repayment schedule.

7.7 Loan or Investment Proposal

The startup of SimEscape LLC will be quite costly. The idea is to start with full scale production as early

as possible to make a big impact on the market before competitors can react.

7.7.1 Amount Requested

The amount that the company calculated would be necessary for startup was a capital investment of

$900,000. This would be the company’s starting equity. The initial bank loan needed was calculated to

be $3,506,000. This would be the company’s starting debt.

7.7.2 Purpose of Uses of Funds

The purpose of the funds raised and loaned would be to purchase a contract with the contract

manufacturing company and to invest in the molds for the injection molding process. The contract

manufacturing contract would then cover the purchase and assembly of electronic parts and the assembly

of the mechanical systems.

7.7.3 Repayment Schedule

The investment repayment schedule is focused on paying back the debt as soon as possible. By using

excess profits to repay as much debt as possible, the company can be repaid by year 3. If the company

fails, the bank would be able to collateralize the inventory of finished product in order to repay debt. The

company has built in an exit strategy by year 3 using a 4 times EBIDA assessment of assets. This metric

places the company at a net value of $4,682,000 at the end of year 3, after tax.

7.7.4 Timetable for implementing plan and launching the business

The company plans to launch full scale production as soon as possible after attaining the necessary funds.

The financial plan assumes the manufacturing contract will be contingent on loan financing, and will only

take 2 weeks until the first production run.



8 Project Management

In order to accomplish the goals of the project the team has set up a structure for task

assignment, accountability, managing funds, planning and scheduling work, and communicating

and sharing information. The following sections outline details of the structure, organization, and

operating procedure of the team.

8.1 Team Organization

Organization is important for the team to keep working smoothly. The team has divided up the

work to be done, identified support personnel who can help them with certain tasks, and set up a

standard for getting work done at meetings and for storing files on the shared drive.

8.1.1 Division of Work

Since the project is divided into three main subsystems, one person has been assigned to each of these

subsystems. Walter has been assigned to manage the video processing subsystem, Dan Ziegler has been

assigned to the computer software that will be needed for the system, and Arnold has been assigned to

work on the motion sensors and data acquisition for the project. These assignments were made based on

the interest and experience of individual team members in each area. The remaining team member, Dan

Bosscher, will work on device power, optics, and PCB layout with Walter, and work with Dan Ziegler and

Arnold on hardware software interface with the motion sensors. Dan Ziegler and Arnold both felt it would

be beneficial to have Dan Bosscher help with this aspect of software because of the number of computer

science courses he has taken. Dan was also given the task of optics because of his contacts in the field.

Additionally, the team might need to use the machine shop to construct the prototype. Since Walter has

taken a machine shop course at Calvin, he will be the one to do the most work on constructing the

prototype.

8.1.2 Team Advisors and Support

The team is advised by primarily by Professor VanderLeest from Calvin College's Engineering

Department, but also by Tim Theriault acting as an industrial consultant from GE Aviation. Other course

instructors are Professors Nielsen, Wunder, and Wentzheimer, all from the Engineering department, and

Professor Medema who is teaching the concurrent Business Aspects for Engineers course. The team has

also received assistance from Michelle Krul, the Engineering Department Administrative Assistant; Bob

DeKraker, the Department Lab Manager; Chuck Holwerda, the Electronics Shop Technician; and Phil

Jasperse the Metal and Wood Shop Technician. Michelle has helped the teams by submitting posters to

printing services, and with organization and announcements for the class. Bob DeKraker orders parts for

the senior design teams. Chuck Holwerda and Phil Jasperse helped with electrical and wood and metal

assembly respectively.

8.1.3 Team Meetings

The team regularly meets on Sunday evenings to discuss coming deadlines and to make sure everyone is

aware of information pertinent to the whole team. The information discussed during meetings includes

dividing up work for upcoming tasks, and making decisions for consistency in the project (such as

naming convention or document formatting).



8.1.4 Storing Files

All documents for the team are being stored on Calvin College's shared drive in the senior design

directory (S://Engineering/Teams/Team03). This folder is divided into sub-folders to separate files by

type. These include Documents, Photos, Posters, and Presentations sub-folders. Additionally there is a

Designs sub-folder that includes software specific files such as Quartus Designs. The Documents folder is

further divided into sub-folders based on document type. This includes Business, Block Diagrams,

Management, PPFS, and Video sub-folders. There was a period of time where team members did not have

write access to this directory. During that time team members stored most information on the personal

machines, and used the Scratch drive (S://Engineering/Scratch/SimEscape Vision) to store documents that

would be needed by the entire group. The team is currently working on moving all documents into the

Team03 folder.

8.2 Schedule

The team has a schedule that they use to track when certain milestones need to be reached for the project,

as well as when they need to turn in material for the class. This schedule, which can be found in Appendix

E, helps to keep the project moving, and lets the team know which due dates are coming up.

8.2.1 Schedule Management

The schedule is maintained by Dan Bosscher who updates it every couple of weeks to take into account

changes in project direction and better understanding of the scope of the project. During the second

semester, the schedule will be updated weekly as major deliverables appear with an increased frequency.

As the team better understands the work that needs to be done for certain tasks, these tasks are then

broken down into more manageable sub-tasks. Sub-tasks are scheduled to take more time than the team

expects, to take into account unforeseen setbacks. The schedule is used to make sure that the highest

levels of tasks meet the set deadlines, and to determine if changes need to be made to meet these

deadlines. If scheduling issues arise, such as being unable to meet an important deadline, the team plans

to meet to discuss if resources can be reallocated to make sure the deadline is made.

8.2.2 Critical Path

The critical path for the project has been divided into two parallel courses, the physical design and the

electrical design. These two paths are shown in Table 20 below, with the top level tasks and due dates for

each section. Two paths are given because the nature of each path allows for a certain amount of

parallelism. The team believes that these are the two paths that hold that greatest amount of risk for them.

If the deadlines in these critical paths are not kept, the team feels that it will not be able finish the project.

At the end of the semester, the two paths will come together to produce a single product.

Table 20. Project Management Critical Paths

Physical Path Electrical Path

Task Due Date Task Due Date

Buy Helmet for

Prototype

01/10/12 Final System Design 01/31/12

Preliminary

Mounting/Optics

02/14/12 Master Schematic 02/14/12

Final Helmet 03/01/12 PCB Layout 03/01/12



Layout/Mounting

Build 03/10/12 Manufacture/Populate

Board

03/07/12

Integration Testing 04/12/12

Mount Electronics on

Helmet

04/25/12 Mount Electronics on

Helmet

04/25/12

8.2.3 Current Progress and Feasibility

The team has made good progress this semester but still has a lot to do. Based on the completion rate

given in the work breakdown schedule (45%) the team believes that it is about 40% done with the project,

taking into account that they have not decided on contingency plans for possible failed tests and expecting

that some tests will fail the first. The team has spent a collective 408.5 hours on the project this semester.

The team has been able to get many of their subsystems working, and they have even already

accomplished some tasks that they were expecting to do second semester. This has been to their

advantage, as the team originally underestimated the amount of work to be done. This means that the

team is not necessarily falling behind, but will have to do a lot of work to accommodate the increased

amount of expected work. Looking ahead at the work that still needs to be done, the team estimates that

they will have around 1000 hours of work to do next semester. Divided between the 16 weeks between

Christmas Break and Senior Design Night (not including Spring Break) this means the team will have to

work around 60 hours a week in order to finish the project on time. The team feels that although this is

more than they anticipated at the beginning of the project, it is still feasible and is looking forward to

presenting a working prototype next semester.

8.3 Budget

The team budget for the project is managed by Dan Ziegler and can be seen in Appendix D – Project

Prototype Budget. The team began the year with an estimate of anything that they would need to purchase

with the budget. With every item that they placed in the budget at the beginning of the year, they gave an

initial cost estimate. After working on the project for about a month, the team reevaluated the budget to

decide if their initial estimates were good, and necessary changes were made. Whenever a purchase is to

be made, the individual making the purchase checks the budget to verify if the purchase is less than or

equal to what was budgeted for it. If this is the case, the budget is updated with the actual amount paid.

Otherwise, if the purchase was not planned for or runs higher than was planned for the team will discuss

alternatives, decide if the purchase is necessary, and decide if money will have to be taken away from

other items in the budget to accommodate the changes.

8.4 Method of Approach

The team approached this project by dividing the entire system for the project into subsystems. For each

subsystem, the team has assigned a specific individual to manage and be held accountable for that

subsystem. That individual will do the majority of the work for the assigned subsystem, including any

research that is needed. All team members are making sure that other members are informed about the

design decisions that they make, especially if a decision made by one member will affect the decisions of

other members. Most of these design decisions are shared by the team during regular meetings.

The team has been using the principles of humility, understanding, trust, openness, and accountability in

their interactions with each other. The team understands that each member has a busy schedule this

semester, and that the work on this project has to be done while also fulfilling a number of other



responsibilities. The team trusts each member to pull his own weight, and to accomplish the tasks that

have been assigned to him. The team expects with humility that there might be delays in smaller sub-tasks

due to other responsibilities, and these delays have been accounted for in the schedule. However, the team

is also holding every member accountable by specifically stating which parts of the project he is

responsible for. To balance this trust and accountability, the team wishes to maintain openness about the

setbacks each member is experiencing, and working with each member to help him meet his deadlines.

9 Conclusions

9.1 Current Progress

The team has been able to effectively work independently and concurrently. Walter Schnoor has been

working on the display system. He has created a prototype of the video processing hardware on a

development board that receives an NTSC 640x480 resolution video input, splits the images, and outputs

a quadrant via VGA to a monitor. This was accomplished in 16 and 24 bit color. Dan Bosscher and

Arnold Aquino have been working on the head tracker unit. They acquired motion tracking sensors and

successfully connected them to a personal computer via a microcontroller. They then were able to read

data from the sensors using software on the microcontroller. Dan Ziegler has been working on

developing input software and utilizing the DX Studio virtual environment software. He has been able to

connect the Vuzix VR920 to control an avatar in DX Studio in stereoscopic 3D using head tracking.

9.1.1 Prototypes

The team has been able to put together working demonstrations of portions of the project. This section

summarizes the portions of the project that have been completed.

9.1.2 Experiments

The experiments performed by the team to demonstrate the feasibility of the design can be seen itemized

below.

9.1.2.1 Display System

Walter Schnoor has set up a NIOS system to take a composite video input and display it through VGA.

He has been able to split up the video into two different outputs by using another Altera DE2 development

board with a VGA output.

9.1.2.2 Software

Dan Ziegler has used DX Studio to build simple virtual environment. He has been mapping the video

output to a side-by-side format and outputting to a Vuzix 920VR through VGA. He has also used the

sensor output from the 920VR and mapped the output to a mouse driver to control the movement of the

cameras in the virtual environment.

9.1.2.3 Head Tracker

Arnold Aquino and Dan Bosscher have been able to wire a pair of sensor breakout boards to an Arduino

Deumilanove microcontroller. They soldered pins to the pin holes of the breakout boards and mounted the

breakout boards to a bread board. They wrote code using Arduino programming language to read and



write to the sensor registers. Arnold and Dan have also started on designing a NIOS II system that

includes an I2C module.

9.1.3 Setbacks

As mentioned in the Virtual Environment Design Selection, the programming language for the Steam

Source SDK was not as user friendly as expected. Dan Ziegler had to research other available software for

creating virtual environments.

Dan Bosscher had a contact for an optometrist who would have been helpful with the optics portion of the

project. However, the optometrist said that he cannot help the team pick out a lens for the optics. This

meant that the team would have to either contact other experts or research optics on their own.

For the sensor circuit, Arnold Aquino found multiple sensor units from Digikey. However, all of the

sensors were surface mount chips. The team will need to have access to equipment that allows for surface

mount population. The design will also include an FPGA with BGA mounting. This will require

sophisticated populating equipment that the team will have to contract out.

9.2 Remaining High Risk Obstacles

Since the team has not ordered all of the parts yet or started putting different portions together, there will

most likely be unforeseen obstacles. There are also defined obstacles that the team has not yet solved.

Two obstacles that the team has determined are high risk based on severity of problem, difficulty of

solution, placement in critical design path, or some combination of these factors are detailed below.

9.2.1 PCB Design

The PCB will be contained in the System Interface Module. Initial design estimates and feedback from

the industrial consultant indicate that the PCB will be a four to six layer board.

9.2.1.1 Problem Statement

The team will have to come up with a way to mount an FPGA to their own board. The team also plans to

design a multi-layer board, which will require research on board layout norms and considerations as well

as a significant amount of time and effort for creating the actual layout. In order to have this complex

board built and populated, the team will have to contract out process to a prototyping company or a PCB

manufacturer. This process will take significant lead time and will therefore need to be done as soon as

possible.

9.2.1.2 Response Strategy

Dan Bosscher works part time at Johnson Controls. Dan is currently talking to Johnson Controls to see if

the hardware group would be willing to advise the team in the design. The team is also trying to leverage

contacts at other local companies to offer services in terms of board creation or population.

9.2.2 Lenses and Lens Mounting

The lenses focus the user’s retina upon the display LCD.

9.2.2.1 Problem Statement



The team will need to come up with a way to mount lenses properly. The lenses will have to be oriented

in a way that gives the user the stereoscopic image effect as well as a clear picture that is easy to focus on.

The lenses would also need to be adjustable so that different users will be able to have the proper focus.

9.2.2.2 Response Strategy

The Vuzix 920VR has adjustable lenses. The team can disassemble the glasses and look at how the

adjustable mechanism works. The team can also approach mechanical engineering students and

professors for some design help. Walter Schnoor has taken shop class which he will apply in the physical

design of the head gear.

10 Credits and Acknowledgements

Team SimEscape would like to give special thanks to Calvin College engineering professor Randall

Brouwer for his assistance in video processing design and programmable logic design.

The team would like to thank Calvin College engineering professor Yoon Kim for giving an insight to the

head tracking portion of the project. Professor Kim recommended using breakout boards and talked about

his experience with sensors.

The team would also like to thank Calvin College engineering professor Steven VanderLeest for advising

the team and always holding the team to a high standard of excellence and professionalism.

The team would like to thank Chuck Holwerda for providing electrical hardware as well as design and

construction expertise.

The team would like to thank Phil Jasperse for teaching a course in metalwork, providing construction

assistance, and for his endless supply of candy in the machine shop.

The team would like to thank Bob DeKraker for his assistance in placing part orders and being a technical

resource.

The team would like to thank James VanDenBerg and Nathan Gelderloos for their contributions to the

formulation of the business strategy and financial predictions.

The team would like to thank Calvin College engineering professor Ned Nielsen for his contributions to

cost analysis.

The team would like to thank GE Aviation employee Tim Theriault for consulting with the team.



11 References 1 Gayle E. Ermer and Steven H. VanderLeest, "Using Design Norms to Teach Engineering Ethics," 2002, http://soa.asee.org/paper/conference/paper-view.cfm?id=16995 2 WiseGeek, What is G-Force?, http://www.wisegeek.com/what-is-g-force.htm 3 Net Market Share, Desktop Top Operating System Share Trend, http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=9&qpcustomb=0 4“Quality of Experience in Virtual Environments”, http://www.neurovr.org/emerging/book4/4_08GAGGIOL.PDF 5 Microsoft, Window Management, http://msdn.microsoft.com/en-us/library/windows/desktop/aa511262.aspx 6D. E. du Toit, “Isokinetic Evaluation of Neck Strength”, http://www.ajol.info/index.php/sasma/article/viewFile/31864/23621 7 United States Department of Labor, How Electrical Current Affects the Human Body,

http://www.osha.gov/SLTC/etools/construction/electrical_incidents/eleccurrent.html 8 Avnet, http://avnet.com/home/ 9 Digikey, http://www.digikey.com/ 10 http://www.wisegeek.com/what-is-g-force.htm 11 Sparkfun, http://www.sparkfun.com/ 12 http://www.digikey.com/ 13 Gamedev.net. GameDev, 1999. Web. 6 Dec. 2011. <http://www.gamedev.net/topic/613786-your-game-engine/>. 14 DX Studio Guide. Ed. Chris S. N.p., 20 June 2010. Web. 14 Nov. 2011. <http://www.dxstudio.com/guide.aspx>. 15 Virtual Reality and Head-Mounted Displays, http://vrguy.blogspot.com/2011/03/side-by-side-3d-and-hmds.html 16 http://vrguy.blogspot.com/2011/03/side-by-side-3d-and-hmds.html 17 http://vrguy.blogspot.com/2011/03/side-by-side-3d-and-hmds.html 18 Average Selling Prices on Graphics Cards Continue to Drop, http://www.xbitlabs.com/news/graphics/display/20090828120338_Average_Selling_Prices_on_Graphics_Cards_Continue_to_Drop_Jon_Peddie_

Research.html 19 Altera Corporation. Video IP Cores for Altera DE Series Boards. July 2010. Tutorial. 20 Ashenden, Peter J. The Designer's Guide to VHDL. San Francisco, CA: Morgan Kaufmann, 1996. Print. 21 Kuon, I.; Rose, J. (2006). "Measuring the gap between FPGAs and ASICs". Proceedings of the internation symposium on Field programmable

gate arrays - FPGA'06. pp. 21. 22 S. Winkler, C. J. van den Branden Lambrecht, and M. Kunt (2001). "Vision and Video: Models and Applications". In Christian J. van den

Branden Lambrecht. Vision models and applications to image and video processing. Springer. p. 209. ISBN 9780792374220. 23 John Watkinson (2008). The art of digital video. Focal Press. p. 272. ISBN 9780240520056. 24 "Converging Lenses." PhysicsLAB. Ed. Catherine H. Colwell. Mainland High School, n.d. Web. 2 Nov. 2011. Path: Resource Lessons;

Geometric Optics; Converging Lenses. 25 Matthias M. Wloka, “Lag in Multiprocessor Virtual Reality”, http://www.google.com/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=2&ved=0CCsQFjAB&url=http%3A%2F%2Fciteseerx.ist.psu.edu

%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.51.8010%26rep%3Drep1%26type%3Dpdf&ei=vSbkTsStG43jggfE3IjhBQ&usg=AFQjCNFCzpH

DJZCjrdtpzJIYjFLOQWGBtA&sig2=UEb6yB7Fm_CBBaMXFKnQJQ 26 “Military Specifications and Standards”, http://www.ihs.com/products/industry-standards/solutions/military-specs.aspx 27The Market for Visual Simulation/Virtual Reality Systems, Sixth Edition, http://www.cyberedge.com/mkt_r_vr_vrmkt6_annc.html 28 Virtual Technologies in Healthcare in the U.S., http://www.kaloramainformation.com/about/editor.asp?id=70 29The Oil & Gas Virtual Reality (VR) Training and Simulation Market 2011-2021, http://www.prnewswire.com/news-releases/the-oil--gas-

virtual-reality-vr-training-and-simulation-market-2011-2021-134579763.html 30 http://www.giiresearch.com/report/kl164671-vr-healthcare.html 31 http://www.prnewswire.com/news-releases/the-oil--gas-virtual-reality-vr-training-and-simulation-market-2011-2021-134579763.html 32 http://www.aviationtoday.com/regions/usa/Pilot-Training-Vital-for-Market-Recovery_44198.html 33 i-Glasses Store. IO Display Systems, 2011. Web. 3 Dec. 2011. <http://www.i-glassesstore.com/i-3d.html>. 34 Liteye HMD. Liteye HMD, 2011. Web. 3 Dec. 2011. <http://www.liteye.com/products/display-products.html>. 35 VR Realities. Rockwell Optronics, 2011. Web. 3 Dec. 2011. <http://www.vrealities.com/sr80.html>. 36 5DT HMD 800 Series. Fifth Dimension Technologies, 2011. Web. 3 Dec. 2011. http://www.5dt.com/products/phmd.html 37 Sensics. Sensics, 2011. Web. 3 Dec. 2011. <http://sensics.com/products/page158/product-selector.php>. 38 Virtual Research Systems Inc.. Virtual Research, 2000. Web. 3 Dec. 2011. <http://www.virtualresearch.com/products/vr1280.htm>. 39 Tek Gear. Mars Hill Group, 2011. Web. 3 Dec. 2011. <http://www.tekgear.com/index.cfm?pageID=90&prodid=595§ion=83>. 40 Cybermind Interactive. Cybermind, 2011. Web. 3 Dec. 2011.

<http://www.cybermindnl.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=50&category_id=11&manufacturer_id

=0&option=com_virtuemart&Itemid=1>. 41 3D Visor. eMagin, 2011. Web. 3 Dec. 2011. <http://www.3dvisor.com/>.

I

12 Appendices

12.1 Appendix A – Angular Velocity Test Data

Angular Velocity Measurement

Usage Speed Time (s)

Speed (deg / s)

Max Speed Time (s)

Speed (deg / s)

Arnold Aquino 10.8 281.5 1.9 842.1

Dan Bosscher 14.2 214.1 2.0 800.0

Walter Schnoor 11.1 273.9 1.9 842.1

Dan Ziegler 11.9 255.5 2.0 800.0

Average 12.0 256.2 2.0 821.1

In order to calculate the average usage speed and the max speed, the team members took turns measuring

and emulating usage. The team measured the time it takes to pan 160 degrees. The time in the table is the

time it took to pan 10 times. One cycle is a total of 320 degrees.

II

12.2 Appendix B - Texas Instruments TMS320C647x Block Diagram

III

12.3 Appendix C – Projected Financials

SimEscape LLC

Pro-Forma Statement of Income

Year 1

Year 2

Year 3 Sales revenue 5,000,000

6,000,000

7,200,000

Variable Cost of Goods Sold -

453,098

1,010,407.50 Fixed Cost of Goods Sold 2,665,280

2,745,238

2,827,595

Depreciation 66,660

88,900

29,620 Gross Margin 2,268,060

2,712,764

3,332,377

Variable Operating Costs 1,248,000

1,497,600

1,797,120 Fixed Operating Costs 193,441

98,803

101,767

Operating Income 826,619

1,116,361

1,433,490 Interest Expense 350,575

315,273

266,475

Income Before Tax 476,045

801,088

1,167,015 Income tax (40%) 190,418

320,435

466,806

Net Income After Tax 285,627

480,653

700,209

SimEscape LLC

Pro-Forma Statement of Cash Flows

Year 1

Year 2

Year 3

Beginning Cash Balance -

4,558,033

5,674,569 Net Income After Tax 285,627

480,653

700,209

Depreciation expense 66,660

88,900

29,620 Invested Capital (Equity) 900,000

900,000

900,000

Distributions to Members -

-

- Increase (decrease) in borrowed funds 3,505,746

(353,017)

(487,975)

Debt Outstanding 3,505,746

3,152,730

2,664,754 Equipment Purchases (200,000)

-

-

Ending Cash Balance 4,558,033

5,674,569

6,816,423

Growth Rate 20%

Price Point 500

Interest Rate 10%

4X EBIDA in year 3 4,681,952

3 Year Return on Equity (Business Sold) 77%

3 Year Return on Equity (Business Retained) 48%

IV

SimEscape LLC

Break - Even Analysis

Year 1

Year 2

Year 3

Sales revenue

5,000,000

6,000,000

7,200,000

Less: Variable Costs:

Variable Cost of Goods Sold -

453,098

1,010,407

Variable Operating Costs

1,248,000

1,497,600

1,797,120

Total Variable Costs

1,248,000

1,950,698

2,807,527

Contribution Margin

3,752,000

4,049,302

4,392,473

Less: Fixed Costs

Fixed Cost of Goods Sold 2,665,280

2,745,238

2,827,595

Fixed Operating Costs

193,441

98,803

101,767

Depreciation

66,660

88,900

29,620

Interest Expense

350,575

315,273

266,475

Total Fixed Costs

3,275,955

3,248,214

3,225,458

Income Before Tax

476,045

801,088

1,167,015

Total Fixed Costs 3,275,955 3,248,214 3,225,458 Contribution Margin % 75% 67% 61% Break Even Sales Volume 4,365,612 4,812,998 5,287,067 Break Even Sales Unit Volume 8,731 9,626 10,574

5

Year 1

Year 2

Year 3

Total Fixed Costs

3,275,955

3,248,214

3,225,458

Contribution Margin % 75%

67%

61%

Break Even Sales Volume

4,365,612

4,812,998

5,287,067

Break Even Sales Unit Volume 8,731

9,626

10,574

Equipment

Depreciation

Purchases

Year 1

Year 2

Year 3

Equipment Purchases Year 1 200,000

66,660

88,900

29,620

Equipment Purchases Year 2 -

-

-

Equipment Purchases Year 3 -

-

66,660

88,900

29,620

MACRS Rates (3-year recovery period) 0.3333

0.4445

0.1481

Interest Expense: Annual interest rate on debt 10%

Year 1

Year 2

Year 3

Average debt balance 1,752,873

3,329,238

2,908,742

Interest expense

175,287

332,924

290,874

Ratio Analysis

Year 1

Year 2

Year 3

Gross Margin of Revenue 0.45

0.45

0.46 Profit Margin 0.06

0.08

0.10

Net Asset Turnover

1.13

1.48

2.02

Debt to Equity Ratio 3.90

3.50

2.96

VI

12.4 Appendix D – Project Prototype Budget

Subsystem Purpose Signal Src Part Name MFG Supplier Est. Cost Qty Total Est.Cost

Head Tracking Tracking Sensor Digital Buy SparkFun $85.00 1 $85.00

Head Tracking Data Acquisition Digital Buy NIOS II Altera Digikey $0.00 1 $0.00

Video Processing Decode Input Mixed Buy Digikey $20.00 1 $20.00

Video Processing Controller Digital Buy Cyclone Altera Digikey $100.00 1 $100.00

Video Processing Displays Digital Buy Digikey $27.00 2 $54.00

Video Processing Development Kit Use DE2, DE2-70 Terasic Calvin College $0.00

Power Power Supply Analog Buy Digikey $50.00 1 $50.00

Power Controller Supply Analog Buy LM317, 7805 Calvin College $0.00 2 $0.00

Power Controller Supply Analog Buy Digikey $1.00 1 $1.00

Packaging Interconnect JCI $50.00 1 $50.00

Packaging Controller HW Build Calvin College $25.00 1 $25.00

Wiring Interconnect AD Buy Calvin College $25.00 1 $25.00

ESTIMATED TOTAL: $410.00

BUDGET: $500.00

REMAINDER: $90.00

VII

12.5 Appendix E – Team Work Breakdown Schedule

# Task Duration Start Date End Date % Done Resources

1 Planning 223.21 days 9/24/2011 4:00 5/5/2012 17:00 9%

2 WBS 212 days 10/6/2011 13:00 5/5/2012 13:00 5%

3 Create WBS 1 day 10/6/2011 13:00 10/7/2011 13:00 100% DB[24]

4 Create Scheduled WBS 10 days 10/7/2011 13:00 10/17/2011 13:00 100% DB[49]

5 Maintain and Update WBS 200 days 10/18/2011 13:00 5/5/2012 13:00 0% DB[0]

6 Project Budget 223.21 days 9/24/2011 4:00 5/5/2012 17:00 13%

7 Preliminary Parts List 26.38 days 10/14/2011 8:00 11/9/2011 17:00 100% AA[1],DB[1],DZ[1],WS[1]

8 Find Cost of Parts 1 day 11/9/2011 17:00 11/10/2011 17:00 100% AA[1],DB[1],DZ[1],WS[1]

9 Revised Parts List 2 days 11/9/2011 17:00 11/11/2011 17:00 100% AA[1],DB[1],DZ[1],WS[1]

10 Draft Budget for Year 2 days 9/24/2011 4:00 9/26/2011 4:00 100% WS[1]

11 Track Expenditures 215.38 days 10/3/2011 8:00 5/5/2012 17:00 0% DZ[1]

12 Keep Budget Up to Date 0 days 10/3/2011 8:00 10/3/2011 8:00 0% DZ[0]

13 Reports/Presentations 436.29 days 2/26/2011 13:00 5/9/2012 4:00 52%

14 Business Plan 67.21 days 10/3/2011 8:00 12/9/2011 13:00 69%

15 Market Analysis 38.21 days 10/3/2011 8:00 11/10/2011 13:00 100%

16 Market Research 31.21 days 10/10/2011 8:00 11/10/2011 13:00 100%

17 Library Consultation 0.21 days 10/10/2011 8:00 10/10/2011 13:00 100% AA[1],DB[1],DZ[1],WS[1]

18 Consult Optometrist 5.21 days 10/15/2011 8:00 10/20/2011 13:00 100% DB[1]

19 Consult Physics/Optics Department

4.21 days 10/24/2011 8:00 10/28/2011 13:00 100% DB[1]

20 Meet with Industrial Consultant 0.17 days 11/10/2011 8:00 11/10/2011 13:00 100% AA[1],DB[1],DZ[1],WS[1]

21 Research Competing Products 4 days 10/31/2011 4:00 11/4/2011 4:00 100% DZ[1]

22 Budget 28.02 days 10/3/2011 8:00 10/31/2011 8:30 100% DZ[1]

23 Design Cost 0.5 hrs 10/3/2011 8:00 10/3/2011 8:30 100% DZ[1]

24 Production Cost 0.02 days 10/3/2011 8:00 10/3/2011 8:30 100% DZ[1]

25 Labor 0.5 hrs 10/3/2011 8:00 10/3/2011 8:30 100% DZ[1]

VIII

26 Materials 0.5 hrs 10/3/2011 8:00 10/3/2011 8:30 100% DZ[1]

27 Marketing 0.5 hrs 10/3/2011 8:00 10/3/2011 8:30 100% DZ[1]

28 Overhead 0.5 hrs 10/3/2011 8:00 10/3/2011 8:30 100% DZ[1]

29 Cost Estimate and Pricing 0.5 hrs 10/31/2011 8:00 10/31/2011 8:30 100% DZ[1]

30 Marketing 0.02 days 10/3/2011 8:00 10/3/2011 8:30 100% AA[1]

31 Identify Target Market 0.5 hrs 10/3/2011 8:00 10/3/2011 8:30 100% AA[1]

32 Define Marketing Strategy 0.5 hrs 10/3/2011 8:00 10/3/2011 8:30 100% AA[1]

33 Write Business Plan 18.21 days 11/21/2011 8:00 12/9/2011 13:00 15%

34 Draft Plan 1 wk 11/21/2011 8:00 11/27/2011 4:00 0% AA[1],DB[1],DZ[1],WS[1]

35 Edit Plan Draft 1 day 11/27/2011 4:00 11/28/2011 4:00 0% AA[1],DB[1],DZ[1],WS[1]

36 Final Draft 1.17 days 12/8/2011 1:00 12/9/2011 13:00 100% AA[1],DB[1],DZ[1],WS[1]

37 Class Presentation 1 day 12/11/2011 13:00 12/12/2011 13:00 0% AA[1],DB[1],DZ[1],WS[1]

38 PPFS 69.88 days 10/3/2011 8:00 12/12/2011 5:00 79%

39 Create Outline 0.33 days 10/3/2011 8:00 10/3/2011 16:00 0% WS[1]

40 Draft PPFS 41.88 days 10/3/2011 16:00 11/14/2011 13:00 99%

41 Title Page 1 day 11/12/2011 13:00 11/13/2011 13:00 100% WS[1]

42 Executive Summary 1 day 11/12/2011 13:00 11/13/2011 13:00 100% WS[1]

43 Project Introduction 40.88 days 10/3/2011 16:00 11/13/2011 13:00 100%

44 Project Definition 1 day 11/12/2011 13:00 11/13/2011 13:00 100% WS[1]

45 Course Overview 33 hrs 11/11/2011 4:00 11/13/2011 13:00 100% DB[2]

46 Stereoscopic Imaging Theory 1 day 10/3/2011 16:00 11/13/2011 13:00 100% DB[1]

47 Team Information 1 day 11/12/2011 13:00 11/13/2011 13:00 100%

48 Arnold Aquino 1 day 11/12/2011 13:00 11/13/2011 13:00 100% AA[1]

49 Dan Bosscher 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

50 Walter Schnoor 1 day 11/12/2011 13:00 11/13/2011 13:00 100% WS[1]

51 Dan Ziegler 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DZ[1]

52 Requirements and Objectives 1.38 days 11/12/2011 4:00 11/13/2011 13:00 99%

53 Design Requirements 1 day 11/12/2011 13:00 11/13/2011 13:00 100%

54 Display System 1 day 11/12/2011 13:00 11/13/2011 13:00 100% WS[1]

IX

55 Head Tracker 1 day 11/12/2011 13:00 11/13/2011 13:00 100% AA[1]

56 Software 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DZ[1]

57 Design Norms 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

58 Designing for Humility 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

59 Designing for Trust 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

60 Designing a Product of Integrity 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

61 Designing as Stewards 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

62 Physical Design 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

63 Product Weight 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

64 Product Size 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

65 Product Materials 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

66 Power Requirements 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

67 Safety 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

68 Electrical Safety 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

69 Physical Safety 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

70 Health Concerns 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

71 Project Management 1.38 days 11/12/2011 4:00 11/13/2011 13:00 99% DB[2]

72 Team Organization 1 day 11/12/2011 4:00 11/13/2011 4:00 100% DB[1]

73 Schedule 1 day 11/12/2011 4:00 11/13/2011 4:00 100% DB[1]

74 Budget 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

75 Method of Approach 1 day 11/12/2011 13:00 11/13/2011 13:00 100% DB[1]

76 System Architecture 1.38 days 11/12/2011 4:00 11/13/2011 13:00 100%

77 Overall System 1 day 11/12/2011 4:00 11/13/2011 13:00 100% WS[1]

78 Head Tracker 1 day 11/12/2011 4:00 11/13/2011 13:00 100% AA[1]

79 Display System 1 day 11/12/2011 4:00 11/13/2011 13:00 100% WS[1]

80 Software 1 day 11/12/2011 4:00 11/13/2011 13:00 100% DZ[1]

81 Electrical System Specifications 2.38 days 11/12/2011 4:00 11/14/2011 13:00 99%

82 Display System 2.38 days 11/12/2011 4:00 11/14/2011 13:00 99% WS[2]

83 Video Processing Platform 2.38 days 11/12/2011 4:00 11/14/2011 13:00 100% WS[1]

X

84 Video Input Format 1.38 days 11/12/2011 4:00 11/13/2011 13:00 100% WS[1]

85 Video Buffers 1.38 days 11/12/2011 4:00 11/13/2011 13:00 100% WS[1]

86 Video Output Format (to the LCDs)

1.38 days 11/12/2011 4:00 11/13/2011 13:00 100% WS[1]

87 Optics 1.38 days 11/12/2011 4:00 11/13/2011 13:00 100% DB[1]

88 Head Tracker 1.38 days 11/12/2011 4:00 11/13/2011 13:00 100% AA[1]

89 Sensors 1.38 days 11/12/2011 4:00 11/13/2011 13:00 100% AA[1]

90 Data Acquisition 1.38 days 11/12/2011 4:00 11/13/2011 13:00 100% AA[1]

91 System Integration 1.38 days 11/12/2011 4:00 11/13/2011 13:00 100% AA[1]

92 Software and Virtual Environment

1 day 11/12/2011 4:00 11/13/2011 4:00 100% DZ[1]

93 Input Interface 1 day 11/12/2011 4:00 11/13/2011 4:00 100% DZ[1]

94 Input Mapping 1 day 11/12/2011 4:00 11/13/2011 4:00 100% DZ[1]

95 Virtual Environment 1 day 11/12/2011 4:00 11/13/2011 4:00 100% DZ[1]

96 Physical System Specifications 1.38 days 11/12/2011 4:00 11/13/2011 13:00 100% DB[1]

97 Helmet 1 day 11/12/2011 4:00 11/13/2011 13:00 100% DB[1]

98 System Interface Module (SIM) Enclosure

1 day 11/12/2011 4:00 11/13/2011 13:00 100% DB[1]

99 Wiring and Interconnection 1 day 11/12/2011 4:00 11/13/2011 13:00 100% DB[1]

100 System Integration Testing 1.38 days 11/12/2011 4:00 11/13/2011 13:00 100% DB[1]

101 Video Delay Testing 1 day 11/12/2011 4:00 11/13/2011 13:00 100% DB[1]

102 Motion Sensitivity Testing 1 day 11/12/2011 4:00 11/13/2011 13:00 100% DB[1]

103 Power Consumption Testing 1 day 11/12/2011 4:00 11/13/2011 13:00 100% DB[1]

104 Business Plan 0.38 days 11/14/2011 4:00 11/14/2011 13:00 100% DZ[1]

105 Market Analysis 0.38 days 11/14/2011 4:00 11/14/2011 13:00 100% DZ[1]

106 Competition 0.38 days 11/14/2011 4:00 11/14/2011 13:00 100% DZ[1]

107 Market Survey 0.38 days 11/14/2011 4:00 11/14/2011 13:00 100% DZ[1]

108 Market Strategy 0.38 days 11/14/2011 4:00 11/14/2011 13:00 100% DZ[1]

109 Cost Estimate 0.38 days 11/14/2011 4:00 11/14/2011 13:00 100% DZ[1]

XI

110 Development 0.38 days 11/14/2011 4:00 11/14/2011 13:00 100% DZ[1]

111 Production 0.38 days 11/14/2011 4:00 11/14/2011 13:00 100% DZ[1]

112 Conclusions 0.38 days 11/13/2011 4:00 11/13/2011 13:00 100% AA[1]

113 Current Progress 0.38 days 11/13/2011 4:00 11/13/2011 13:00 100% AA[1]

114 Prototypes 0.38 days 11/13/2011 4:00 11/13/2011 13:00 100% AA[1]

115 Experiments 0.38 days 11/13/2011 4:00 11/13/2011 13:00 100% AA[1]

116 Setbacks 0.38 days 11/13/2011 4:00 11/13/2011 13:00 100% AA[1]

117 Remaining Obstacles 0.38 days 11/13/2011 4:00 11/13/2011 13:00 100% AA[1]

118 Obstacle-PCB Design 0.38 days 11/13/2011 4:00 11/13/2011 13:00 100% AA[1]

119 Obstacle-Lenses and Lens Mounting

0.38 days 11/13/2011 4:00 11/13/2011 13:00 100% AA[1]

120 Credits and Acknowledgements 1.38 days 11/13/2011 4:00 11/14/2011 13:00 100% WS[1]

121 References 1.38 days 11/13/2011 4:00 11/14/2011 13:00 100% WS[1]

122 Appendices 1.38 days 11/13/2011 4:00 11/14/2011 13:00 100% WS[1]

123 Final Draft PPFS 27.67 days 11/14/2011 13:00 12/12/2011 5:00 0% AA[1],DB[1],DZ[1],WS[1]

124 Peer Review 7 days 11/14/2011 13:00 11/21/2011 13:00 0% Outside

125 Editing 9 days 12/3/2011 4:00 12/12/2011 4:00 0% AA[1],DB[1],DZ[1],WS[1]

126 Address Comments 9 days 12/3/2011 4:00 12/12/2011 4:00 0% AA[1],DB[1],DZ[1],WS[1]

127 Submit Final Draft 1 hr 12/12/2011 4:00 12/12/2011 5:00 0% AA[1],DB[1],DZ[1],WS[1]

128 Final Presentation 58 days 3/12/2012 4:00 5/9/2012 4:00 0%

129 Create Poster 2 days 5/2/2012 13:00 5/4/2012 13:00 0%

130 Team Description 1 hr 3/14/2012 4:00 3/14/2012 5:00 0%

131 Create Presentation 4.21 days 4/30/2012 8:00 5/4/2012 13:00 0%

132 Create PowerPoint 3 days 4/30/2012 13:00 5/3/2012 13:00 0%

133 Divide Speaking Roles 1 hr 4/30/2012 8:00 4/30/2012 9:00 0% AA[1],DB[1],DZ[1],WS[1]

134 Practice Presentation 1 day 5/3/2012 13:00 5/4/2012 13:00 0% AA[1],DB[1],DZ[1],WS[1]

135 Final Report 58 days 3/12/2012 4:00 5/9/2012 4:00 0%

136 Write Draft Final Report 39 days 3/12/2012 4:00 4/20/2012 4:00 0%

137 Create Final Report Outline 2 hrs 3/12/2012 4:00 3/12/2012 6:00 0% AA[1],DB[1],DZ[1],WS[1]

XII

138 Divide Work 1 hr 3/12/2012 6:00 3/12/2012 7:00 0% AA[1],DB[1],DZ[1],WS[1]

139 Write Draft 37 days 3/12/2012 7:00 4/18/2012 7:00 0% AA[1],DB[1],DZ[1],WS[1]

140 Executive Summary 1 day 4/4/2012 4:00 4/5/2012 4:00 0%

141 Compile 1 day 4/19/2012 4:00 4/20/2012 4:00 0%

142 Edit Final Report 18 days 4/21/2012 4:00 5/9/2012 4:00 0%

143 Read and discuss comments 1 day 4/21/2012 4:00 4/22/2012 4:00 0% AA[1],DB[1],DZ[1],WS[1]

144 Address Comments 17 days 4/22/2012 4:00 5/9/2012 4:00 0% AA[1],DB[1],DZ[1],WS[1]

145 Website 163.83 days 10/17/2011 8:00 3/29/2012 4:00 96%

146 Post Website 56.21 days 10/17/2011 8:00 12/12/2011 13:00 100%

147 Home Page 5.33 days 10/17/2011 8:00 10/23/2011 8:00 100% DZ[128],WS[128]

148 Bios 5.33 days 10/17/2011 8:00 10/23/2011 8:00 100% DZ[128],WS[128]

149 Project Description 5.33 days 10/17/2011 8:00 10/23/2011 8:00 100% DZ[128],WS[128]

150 Current Progress 5.33 days 10/17/2011 8:00 10/23/2011 8:00 100% DZ[128],WS[128]

151 WBS 1 hr 12/12/2011 12:00 12/12/2011 13:00 100% WS[1]

152 Upgrade Website 1 day 3/28/2012 4:00 3/29/2012 4:00 0% WS[1]

153 Keep Website Updated 0 days 12/13/2011 4:00 12/13/2011 4:00 0% DZ[0],WS[0]

154 Presentations 378.67 days 4/13/2011 4:00 4/27/2012 4:00 59%

155 Presentation 1 5.38 days 10/16/2011 8:00 10/21/2011 17:00 100% DB[1],AA[1]

156 Presentation 2 13.29 days 11/25/2011 8:00 12/8/2011 16:00 100% DZ[1],WS[1]

157 Presentation 3 7.33 days 2/20/2012 4:00 2/27/2012 13:00 0%

158 Presentation 4 6 days 4/21/2012 4:00 4/27/2012 4:00 0%

159 Fridays Presentation 0.33 days 11/11/2011 4:00 11/11/2011 13:00 100% AA[1],DB[1],DZ[1],WS[1]

160 Fridays Presentation 2 1 hr 4/13/2011 4:00 4/13/2011 5:00 0% AA[1],DB[1],DZ[1],WS[1]

161 Updated Poster 2 days 11/7/2011 8:00 11/9/2011 8:00 0% WS[1]

162 Updated Poster 2 1 day 4/10/2011 4:00 4/11/2011 4:00 0%

163 Demos Ready 1 day 4/10/2011 4:00 4/11/2011 4:00 0%

164 Project Brief for Industrial Consultant

1 day 2/26/2011 13:00 2/27/2011 13:00 0%

165 Design 208.83 days? 10/3/2011 8:00 4/29/2012 4:00 45%

XIII

166 Critical Path 101.38 days 1/4/2012 4:00 4/14/2012 13:00 0%

167 Physical 62.67 days 1/9/2012 13:00 3/12/2012 5:00 0%

168 Buy Helmet for Prototype 1 day 1/9/2012 13:00 1/10/2012 13:00 0%

169 Preliminary Mounting and Optics

14.08 days 1/9/2012 13:00 1/23/2012 15:00 0%

170 Optics 8 days 1/9/2012 13:00 1/17/2012 13:00 0%

171 Identify Lenses 1 day 1/9/2012 13:00 1/10/2012 13:00 0%

172 Order Lenses 7 days 1/10/2012 13:00 1/17/2012 13:00 0%

173 Design & Testing 6.08 days 1/17/2012 13:00 1/23/2012 15:00 0%

174 Mock Mounting Setup 1 day 1/17/2012 13:00 1/18/2012 13:00 0%

175 Vision Focus Testing 5.08 days 1/18/2012 13:00 1/23/2012 15:00 0%

176 Define Test Method 4 days 1/18/2012 13:00 1/22/2012 13:00 0%

177 Perform Test 1 day 1/22/2012 13:00 1/23/2012 13:00 0%

178 Evaluate Results 2 hrs 1/23/2012 13:00 1/23/2012 15:00 0%

179 Adjust if Test Failed 0 days 1/23/2012 15:00 1/23/2012 15:00 0%

180 Comfort Testing 5.08 days 1/18/2012 13:00 1/23/2012 15:00 0%


182 Perform Test 1 day 1/22/2012 13:00 1/23/2012 13:00 0%



185 Final Helmet Design 3 days 2/14/2012 4:00 2/17/2012 4:00 0%

186 Finalize Layout 1 day 2/14/2012 4:00 2/15/2012 4:00 0%

187 Finalize Mounting 1 day 2/15/2012 4:00 2/16/2012 4:00 0%

188 Finalize Routing 1 day 2/16/2012 4:00 2/17/2012 4:00 0%

189 Build 4.67 days 3/7/2012 13:00 3/12/2012 5:00 0%

190 Mount Lenses 1 day 3/7/2012 13:00 3/8/2012 13:00 0% WS[1]

191 Build Enclosure 4.04 days 3/8/2012 4:00 3/12/2012 5:00 0% WS[1]

192 Build Casing 4 days 3/8/2012 4:00 3/12/2012 4:00 0% WS[1]

193 Place PCB in Casing 1 hr 3/12/2012 4:00 3/12/2012 5:00 0%

XIV

194 Acquire Wires for Routing 2 days 3/9/2012 4:00 3/11/2012 4:00 0%

195 Electrical 95.08 days 1/4/2012 4:00 4/8/2012 6:00 0%

196 Final System Design 14.04 days 1/4/2012 4:00 1/18/2012 5:00 0%

197 Identify All Components 1 wk 1/4/2012 4:00 1/10/2012 0:00 0%

198 Identify Power Requirements 2 days 1/10/2012 0:00 1/12/2012 0:00 0%

199 Component Interconnect 2 days 1/10/2012 4:00 1/12/2012 4:00 0%

200 Test Design on Breadboard 8.04 days 1/10/2012 4:00 1/18/2012 5:00 0% WS[1],AA[1]

201 Test Motion Tracking 6.04 days 1/12/2012 4:00 1/18/2012 5:00 0%


203 Perform Test 2 days 1/16/2012 4:00 1/18/2012 4:00 0%

204 Evaluate Results 1 hr 1/18/2012 4:00 1/18/2012 5:00 0%

205 Adjust if Test Failed 0 hrs 1/18/2012 5:00 1/18/2012 5:00 0%

206 Test LCD Output 6.04 days 1/10/2012 4:00 1/16/2012 5:00 0%



209 Evaluate Results 1 hr 1/16/2012 4:00 1/16/2012 5:00 0%

210 Adjust if Test Failed 0 hrs 1/16/2012 5:00 1/16/2012 5:00 0%

211 Master Schematic 18.79 days 1/18/2012 5:00 2/6/2012 0:00 0%

212 Specify Part Sizes 2 hrs 1/18/2012 5:00 1/18/2012 7:00 0% DB[1]

213 Preliminary parts layout 1 wk 1/18/2012 7:00 1/24/2012 3:00 0% WS[1],DB[1]

214 Revise Layout and verify connections

1 wk 1/31/2012 4:00 2/6/2012 0:00 0%

215 PCB Layout 7.83 days 2/14/2012 4:00 2/22/2012 0:00 0%

216 Get access to design software 2 days 2/14/2012 4:00 2/16/2012 4:00 0% WS[1]

217 Generate PCB Design 1 wk 2/16/2012 4:00 2/22/2012 0:00 0% WS[1],DB[1]

218 Manufacture/Populate Board 9 days 3/1/2012 4:00 3/10/2012 4:00 0%

219 Integration Testing 29.08 days 3/10/2012 4:00 4/8/2012 6:00 0%

220 System Response and Accuracy Testing

6.08 days 3/10/2012 4:00 3/16/2012 6:00 0%

XV





225 Latency Testing 6.08 days 3/26/2012 4:00 4/1/2012 6:00 0%





230 Sensitivity Testing 6.08 days 4/2/2012 4:00 4/8/2012 6:00 0%





235 Mounting 6.29 days 4/8/2012 6:00 4/14/2012 13:00 0%

236 Mount Enclosure 1 day 4/8/2012 6:00 4/9/2012 6:00 0% WS[1]

237 Mount LCD 1 day 4/12/2012 13:00 4/13/2012 13:00 0%

238 Connect All Systems 1 day 4/13/2012 13:00 4/14/2012 13:00 0% WS[1]

239 Determine Acceptable Weight 97.04 days 10/3/2011 8:00 1/8/2012 9:00 0%

240 Develop Test 2 days 10/3/2011 8:00 10/5/2011 8:00 0%

241 Preliminary Testing in Group 2 hrs 1/6/2012 4:00 1/6/2012 6:00 0%

242 Preliminary Results 1 hr 1/6/2012 6:00 1/6/2012 7:00 0%

243 Expanded Testing 2 days 1/6/2012 7:00 1/8/2012 7:00 0%

244 Compile Results and Set Weight 2 hrs 1/8/2012 7:00 1/8/2012 9:00 0%

245 Data Acquisition 103.83 days 10/3/2011 8:00 1/15/2012 4:00 87% AA[1.87]

246 Select Accelerometer/Gyroscope 35.38 days 10/3/2011 8:00 11/7/2011 17:00 100% AA[1]

247 Define Requirements 15.38 days 10/3/2011 8:00 10/18/2011 17:00 100% AA[1]

248 Find Acceptable Parts 32.38 days 10/3/2011 8:00 11/4/2011 17:00 100% AA[1]

249 Select Sensor From List of 35.38 days 10/3/2011 8:00 11/7/2011 17:00 100% AA[1]

XVI

Acceptable Parts

250 Test Output of Motion Sensor 1 hr 11/23/2011 13:00 11/23/2011 14:00 100% AA[1]

251 Design Motion Tracking Circuit 72 days 11/4/2011 4:00 1/15/2012 4:00 32% AA[1]

252 Define Implementation Strategy 34 days 11/4/2011 4:00 12/8/2011 4:00 100% AA[1.97]

253 Determine Analog vs Digital 1 day 11/4/2011 4:00 11/5/2011 4:00 100% AA[1]

254 Determine I2C vs SPI 1 day 12/7/2011 4:00 12/8/2011 4:00 100% AA[1]

255 Determine Acceptable Noise Level

5.04 days 1/9/2012 4:00 1/14/2012 5:00 0%

256 Develop Test 5.04 days 1/9/2012 4:00 1/14/2012 5:00 0%

257 Develop Test Method 4 days 1/9/2012 4:00 1/13/2012 4:00 0%

258 Perform Test 1 day 1/13/2012 4:00 1/14/2012 4:00 0%

259 Evaluate Results and Define Acceptable Noise Level

1 hr 1/14/2012 4:00 1/14/2012 5:00 0%

260 Build on Breadboard 4 days 11/19/2011 4:00 11/23/2011 13:00 100% AA[1]

261 Design FPGA Module for DAQ 3 days 1/9/2012 4:00 1/12/2012 4:00 0% AA[1]

262 Design Sensors to be Implemented in PCB Design

3 days 1/12/2012 4:00 1/15/2012 4:00 0% AA[1]

263 Make Design Adjustments 2 days 1/12/2012 4:00 1/14/2012 4:00 0% AA[1]

264 Video Processing 85 days 10/17/2011 4:00 1/10/2012 4:00 40% WS[1]

265 Select LCDs 42.38 days 10/17/2011 4:00 11/28/2011 13:00 100% WS[1]

266 Define Requirements 1 day 10/17/2011 4:00 10/18/2011 4:00 100% WS[1]

267 Research Available Parts 2 days 10/18/2011 4:00 10/20/2011 4:00 100% WS[1]

268 Make Selection 1 day 11/27/2011 13:00 11/28/2011 13:00 100% WS[1]

269 ADC 3 days 1/4/2012 4:00 1/7/2012 4:00 0% WS[1]

270 Program FPGA 3 days 1/7/2012 4:00 1/10/2012 4:00 0% WS[1]

271 Software 208.83 days? 10/3/2011 8:00 4/29/2012 4:00 73% DZ[1]

272 Define Requirements 2 days 10/29/2011 4:00 10/31/2011 4:00 0% DZ[1]

273 Make Overall Software Design 2 days 11/1/2011 4:00 11/3/2011 4:00 0% DZ[1]

274 Select Graphics Engine 21.21 days 10/3/2011 8:00 10/24/2011 13:00 100% DZ[1]

XVII

275 Define Requirements 17.21 days 10/3/2011 8:00 10/20/2011 13:00 100% DZ[1]

276 Research Available Software 18.21 days 10/3/2011 8:00 10/21/2011 13:00 100% DZ[1]

277 Select Software Based on Needs 21.21 days 10/3/2011 8:00 10/24/2011 13:00 100% DZ[1]

278 Identify Video Output of Engine 1 day 11/10/2011 4:00 11/11/2011 4:00 100% DZ[1]

279 Use Engine to Generate Usable Output

1 hr 11/11/2011 13:00 11/11/2011 14:00 100% DZ[1]

280 Build Demonstration Environment

114 days 1/6/2012 4:00 4/29/2012 4:00 0% DZ[1]

281 Research Using Autodesk Models with Engine

1 day 1/6/2012 4:00 1/7/2012 4:00 0% DZ[1]

282 Define Process for Importing Autodesk Models

1 day 1/6/2012 4:00 1/7/2012 4:00 0% DZ[1]

283 Import Model 1 day 4/28/2012 4:00 4/29/2012 4:00 0% DZ[1]

284 Input Interface Software 14.67 days? 2/6/2012 8:00 2/21/2012 0:00 0% DZ[1]

285 Determine Method of Communication with Sensors

2 days 2/6/2012 8:00 2/8/2012 8:00 0% DZ[1],AA[1]

286 Define Program Behavior 3 days 2/8/2012 8:00 2/11/2012 8:00 0% DZ[1]

287 Develop Test Method to Verify Working Code

2 days 2/13/2012 4:00 2/15/2012 4:00 0% DZ[1]

288 Write Code 5.83 days? 2/15/2012 4:00 2/21/2012 0:00 0% DZ[1]

289 Write Code 0 days? 2/21/2012 0:00 2/21/2012 0:00 0%

290 Implement Software Noise Filters

1 day? 2/15/2012 4:00 2/16/2012 4:00 0%

291 Test Code 1 day 2/16/2012 4:00 2/17/2012 4:00 0% DZ[1]

292 Consolidate Software 1 wk 2/23/2012 0:00 2/28/2012 20:00 0%

293 Purchase Parts 34.38 days 11/12/2011 4:00 12/16/2011 13:00 0% AA[1],DB[1],DZ[1],WS[1]