2 .edu
Computer Control of
Theater Performance Electronics
Project Plan
Clients:
Iowa State Dance
Co-Motion Dance Company
Faculty Advisors:
Dr. Gerald Sheble
Dr. Julie Dickerson
Team: SDMay06-18
Tarun Bhatia
Amanda Farniok
Sheng Ly
Alex Sills
Submitted: October 11, 2005
DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.
Table of Contents
1 Project Overview 1
1.1 Abstract 1
1.2 Acknowledgement 1
1.3 Problem Statement 1
General Problem Statement 1
General Solution Approach 1
1.4 Operating Environment 2
1.5 Intended Users and Intended Uses 2
Intended Users 2
Intended Uses 2
1.6 Assumptions and Limitations 3
Initial Assumptions List 3
Initial Limitations List 3
1.7 Expected End Product and Other Deliverables 3
Documentation 4
Due 1st Week of May 2006 4
2 Proposed Approach 4
2.1 Functional Requirements 4
2.2 Constraint Considerations 4
2.3 Technology Considerations 5
2.4 Technical Approach Considerations 5
2.5 Testing Requirements Considerations 6
2.6 Security Considerations 6
2.7 Safety Considerations 6
2.8 Intellectual Property Considerations 6
2.9 Commercialization Considerations 6
2.10 Possible Risks and Risk Management 7
2.11 Proposed Milestones and Evaluation Criteria 7
2.12 Project Tracking Procedures 9
3 Statement of Work 10
Task 1 – Project Familiarization 10
Task 2 – Research for Transmitter/Receiver 10
Task 3 – Putting Hardware Together 10
Task 4 – Research of Isadora Software Development 11
Task 5 – Testing of Software Environments 11
Task 6 – Understanding 12
Task 7 – Setting up the system for the client 12
Task 8 – Research of auxiliary technologies 13
4 Estimated Resources and Scheduling 13
5 Project Team Information 16
Client Information: 16
Faculty Advisor Information: 16
Team Member Information 18
5.1 Closing Summary 19
5.2 References 20
List of Tables
Table 1. Milestone Evaluation Ratings 8
Table 2. Personal Task Allocation 12
Table 3. Itemized Project Resources Needed 12
Table 4. Estimate, Itemized Cost of Rescources 13
List of Figures
Figure 1. Pie Chart for Weights of Milestones 9
Figure 2. Anticipated Hardware Setup 10
Figure 3. Timeline, Dependencies, and Breakdowns of Tasks 15
List of Definitions
Apparatus - The whole of the end product design which includes all of the hardware on the body of the user combined with the receiver and computer equipment used to control the environment.
Electromagnetic Noise - Interference with data signal as a result of radio wave radiation by other electronic devices.
Isadora - Isadora is a graphic programming environment that provides interactive control over digital media, with special emphasis on the real-time manipulation of digital video.
Piezo - Sensor that sends an impulse through a wire connection when tapped with a slight impact.
SDK - Software development kit
UML(Unified Modeling Language) - A visual language for specifying, constructing and documenting the artifacts of the system.
MIDI(Musical Instrument Digital Interface) - Standard specifications that enable electronic instruments such as the synthesizer, sampler, sequencer, and drum machine from any manufacturer to communicate with one another and with computers.
1 Project Overview
1.1 Abstract
Performers of modern dance require more dancer interactive means of presenting their productions. Current control of theater visual aids used by Iowa State Dance and Co-Motion Dance Company is limited to preprogrammed routines, camera input, and limited remote input via primitive sensors. This project seeks to use dancer movement as input to control the operation of visual aids in a dance/theater performance. Using sensors on the bodies of dancers, which send a signal via transmitter to a receiver connected to a computer using the software Isadora, the dancers will be able to manipulate the visual equipment of the performance using their own movements. The clients require one working receiver and transmitter pair by the end of the project with the design allowing for expansion to 4 or more receiver and transmitter pairs (dancers). This development will add a new degree of freedom and creativity to the performances of Iowa State Dance and Co-Motion Dance Company.
1.2 Acknowledgement
The design team would like to acknowledge the clients Janice Baker of Iowa State Dance and Valerie Williams of Co-Motion Dance Company. Ms. Williams and Ms. Baker’s dancers will be using the end product. Thanks are also extended to Dr. Gerald Sheble and Dr. Julie Dickerson who are the faculty advisors for the project. They will serve as technical consultants as well as counselors to aid the steady progress of the project.
1.3 Problem Statement
General Problem Statement
The members of Iowa State Dance and Co-Motion Dance Company would like to be able to control their own visual dance environment without the help of stagehands or technicians. To remedy this, the directors of these groups requested a dancer-operated sensor pack which sends input to be received by a computer program called Isadora. Isadora can then be programmed to control lighting, video projection, and other characteristics of the dancer’s stage environment. The clients require an apparatus capable of transmitting four sensor inputs from four different dancers (16 sensors in total) to a computer running Isadora. Isadora will then need to be set up to receive these inputs via hardware and software. It is desired that the different types of sensors (touch, flex, mic) be interchangeable with the rest of the apparatus. Power supply to the transmitters also needs to be as user-friendly as possible, so either common dry cell batteries or a conveniently rechargeable battery pack is desired. In addition, packaging needs to be designed to keep the sensors and transmitters protected from the elements such as sweat, physical impacts, and heat during their use.
General Solution Approach
The clients have demonstrated sensors that have worked in the past and they see no reason for a change in sensor choices. Packaging will need to be considered for the sensors and transmitter pack so that they are adequately protected and also protect the users from electric shock. This will require research of different fabrics and possible stitching/sewing techniques. Wires connecting the sensors to the transmitter will also need to be contained and kept away from distrubances. A large milestone in the project will be finding a transmitter/receiver apparatus that works well and also has the capability for expansion to receive multiple transmitters. The receiver will also need to be set up to send input to the Isadora computer through a USB, firewire, or some other appropriate hardwire connection. A sensor watcher program will need to be designed in Isadora to take the transmitted sensor input and use it effectively to manipulate the stage environment. Interchangeability of batteries and sensors will be a consideration when choosing hardware for the project.
1.4 Operating Environment
The end product will be used extensively in theatrical dance settings such as the Forker Theater, Fischer Theater, Stephens Auditorium, and the Ames City Auditorium. These environments inherently contain much ambient electromagnetic noise caused by the multitude of electrical equipment in the immediate vicinity. Consideration and research will be done on this subject to acquire as much information as possible about this issue in order to prevent any complications. The sensors and transmitter pack will have to be designed to withstand substantial abuse caused by the motion of the dancers, their impact with the floor or wall, and the sweat and heat that their bodies produce during performance.
1.5 Intended Users and Intended Uses
Intended Users
The end product will be designed to be used by a team consisting of members of Iowa State Dance, members of Co-Motion Dance Company, and their directors. The end product will be designed such that any dancer could easily observe its operation or read the documentation and be able to operate the apparatus, given a pre-written Isadora routine with which to handle the input. It will be the responsibility of the users to design an appropriate module in Isadora to deal with the inputs transmitted by the apparatus and subsequently operate the visual aids. As such, designing a completely original visual accompaniment will require the skills of a versed user of Isadora. However, all the hardware connections will be largely intuitive to any user with a beginner’s level computer background.
Intended Uses
Iowa State Dance and Co-Motion Dance Company request they be able to use the end product in their practices, performances, and productions. The apparatus should be usable in any situation analogous to the conditions of these groups’ activities. The device will be designed to work in an environment where the transmitter is at most a range of 60 feet from the receiver, the impacts inflicted on the transmitter and sensor are minor, and the ambient electromagnetic noise is kept to a minimum. As such, the device will not be designed to operate in an environment of increased electromagnetic noise, nor will it be suited to operate in an environment more broad, impact-prone, or otherwise hazardous than that of a dance performance.
1.6 Assumptions and Limitations
Initial Assumptions List
Assumptions are constraints of the project outside of the design team’s control. They have been ascertained through discussion with the clients and advisors.
• The sensors used now are satisfactory and will be used.
• 1/8” mini-plug jacks/plugs will be used for sensor/transmitter connection for ease of use and interchangeability if still possible.
• There will not necessarily be a clear line of sight from the transmitter to the receiver.
• There will be electromagnetic noise present in the operating environment.
• The receiver and computer as well as the visual aids will run on power supplied from an external source.
Initial Limitations List
Limitations are constraints of the project within the control of the design group. They have been compiled through discussion with the clients and advisors.
• The end product will be only one transmitter/receiver pair but will allow for expansion for up to four transmitters.
• The end product shall not exceed the budget of $150.
• The end product must be small and compactly packaged to allow for full range of motion by the user.
• The distance from the transmitter to the receiver will be at most 60 feet.
• The transmitter will need to have sufficient power to operate for at least the duration of an ISU/Co-Motion dance production.
1.7 Expected End Product and Other Deliverables
End product (four-sensor transmitter, receiver with computer interface, sensor watcher program for Isadora)
All end product deliverables will be provided to the clients by the 2nd Week of March 2006.
The final delivered product will consist of three main parts. The first part worn by the dancer will consist of four sensors connected to the transmitter. All these parts will be packaged in appropriate material to prevent damage to the device and harm to the dancer. Next, the receiver will be supplied along with an appropriate interface cable with which to connect it to the Isadora computer. Finally, the sensor watcher written for Isadora will be delivered in software format in order to use the hardware. Batteries/battery pack will be included for the transmitter.
Documentation
Due 1st Week of May 2006
All documentation created and completed throughout the project will be supplied to the end users and clients. This includes the project plan, design report, and final report. The project poster can be made available in software form and smaller hard copy if desired. This documentation should include any schematics and other such technical information relevant to the end product. If requested, a simple “How To” manual could also be written and provided easily.
2 Proposed Approach
This section shall outline the planned method for completing the project. It will include an approach for building a module that reads the piezo and the flex sensors as inputs which manipulates the video from the digital camera in Isadora.
2.1 Functional Requirements
The following functions shall be required to successfully complete the project.
• Designing Module for Isadora
The module (sensor-watcher) should be able to identify the transmitter and identify the data transmitted from the four sensors connected to that transmitter.
• Complete Hardware
The transmitter/receiver should be communicating to the USB port of the laptop and each sensor to the transmitter.
• Additional Requirements
The module should be coded such that it could support four transmitters if so desired.
2.2 Constraint Considerations
The entire project shall run under the following constraints and considerations.
• Safety
The sensors should not rust under sweat or induce shocks to the dancers. The equipment has to have padding between the skin and the circuit to reduce wear and tear.
• Durability
The system must be durable, long lasting, and secure. The soldering should be done properly to prevent breakage of the circuit. The sensors should be of high quality to prevent lag.
• Hardware Requirements
The hardware should be able to able to work in big auditorium settings. It should be able to filter static and produce clean appropriate data. It should not lose data when it’s not in visible range to the receiver.
• Software Requirements
The software should be able to read and identify data input from each sensor connected to the transmitter. The software should also be able to manipulate the range of the flex sensor and the trigger of piezo sensor for video output.
• Additional Software Requirements
The standard coding platform being Macintosh might hinder understanding coding architecture for Isadora software. It might also burden producing testing version for the module in Windows platform. The software has to be able to read the sensor inputs in voltage and convert it as a MIDI which is what Isadora recognizes.
• Connectivity Requirements
The system must communicate exclusively over a standard laptop.
2.3 Technology Considerations
The project should run under the following technology considerations:
• The release version for Isadora with the sensor module should be able to run parallel in a Macintosh or a Windows version.
• Newer technologies like Bluetooth and Infrared with different bandwidths should be researched for inheriting better reception from the transmitter to the receiver.
• Define amplifier needs if there is a lot of data loss.
• Project has to be created while keeping a multi transmitter/receiver prototype in mind.
2.4 Technical Approach Considerations
Each sensor has to be configured to interface with the computer/laptop on which the end output is desired. TinyOS software will be used for this and is an open source project available to the public for free. When the circuit is connected to the laptop through a USB port, TinyOS could configure the receiver and the transmitter. It will also help to identify each sensor by giving it a unique ID. After the circuit is configured, TinyOS should be able to deliver inputs as voltage for each sensor connected to the circuit.
The Piezo sensors and the flex sensors are soldered to the transmitter using insulated copper wires. As an end product, each transmitter should be able to support four sensors. The wires are to be long enough to extend to several different parts of the body.
After the initial circuit setup and connection to the laptop, an interface would read those voltage inputs and convert them into MIDI inputs. The interface would be designed on an Isadora platform. The interface should run in the background of a module written in C++ for Isadora. The end user should be able to see the module in Isadora where they could just add and drop the module on the workspace and make connection to the video with it. The module should then be used to trigger or alter the video feed coming from a digital camera also connected to the laptop.
2.5 Testing Requirements Considerations
The following is a definition of the methodologies and acceptance criteria to be used in the testing of the intermediate and end-products resulting from this product.
• Hardware Testing
At each iteration of circuit design development, the hardware group should test to make the circuit shock proof. There should be testing done on sensors for corrosion because of sweat by the dancers that would wear them. The hardware group would also make the circuit static free so that there is least amount of data loss due to sound and magnetic field from lights and electrical equipment in the room.
• Software Testing
At each iteration, while making the interface and the module for the client, the software group should be testing for bugs and memory leaks due to the use of pointers while writing code that could result in system breakdown. The software group should be testing for optimum source code that could manipulate the data feed accurately and precisely.
• Iterative and Final Testing
Testing must occur before the system is provided to the client. Testing has to be iterative so that the problems with the electrical circuit or the bugs in the software can be handled as they are identified.
2.6 Security Considerations
Both Isadora and Tiny OS are open source software. The project is designed for the artists in the music and theatre industry. The end software product will be free and for anyone to use. However, the hardware would be unique for this project and would only be the property of the client.
2.7 Safety Considerations
The hardware design has to be built such that it is durable and shock proof. While building the circuit board for the receiver, normal wear and tear should be considered. The dancer that wears the transmitter circuit should have long enough wires such that the body movements are not compromised but also not so long that there is a chance of cluttering.
2.8 Intellectual Property Considerations
The hardware and the software design would be available to the public after the product is complete. The client wishes to distribute her share to the public as it could benefit other theatre performances as well. The only consideration for the team should be the recognition of their individual efforts for the project.
2.9 Commercialization Considerations
The software product would be available as a CVS project on the sourceforge website for designers that would want to use the code. The equipment for the project would be designed just for the client and thus, could not be further marketed.
2.10 Possible Risks and Risk Management
Several possible project risks are identified:
• Procurement of Materials
All necessary hardware and components must be obtained before construction of the circuit for the transmitter and the receiver. Any delays (e.g. backorder/limited stock, loss, damage, or delay by parcel service) in the receipt of these items may cause significant delays in the overall progress of this project. To reduce these effects a complete bill of materials will be assembled and parts will be ordered before semester break to ensure enough time for delivery of all materials.
• Data Loss
Any type of software development involves the risk of data and/or code loss either by hardware failure, or by careless/unauthorized use. Adequate backup of data and code will help to minimize this risk.
• Physical Damage
Damage to any components may significantly hinder project performance and progress. Vandalism and user misuse/abuse may also contribute to malfunction of the system. Electronic hardware is at notably high risk for damage by electro-static discharge during the construction of unit. Proper soldering and insulation of the equipment, and all its internal hardware and cautious handling of all internal components will minimize this risk.
• Loss of Team Member
Any project team must consider the loss of a team member. As this project is in its initial stage, loss of any team member would be crucial to the project. Most of the information will be stored locally on a website. This website will be instrumental in containing program files and documentation produced by the team. A centralized information location will reduce the likely hood of losing information with the loss of a team member.
2.11 Proposed Milestones and Evaluation Criteria
• Project Research and Familiarization
Members of team will have to fully understand the system’s hardware construction and its software design and functionality. This will be essential for the success of the project. The client will evaluate the success of this milestone. If the client feels that the team has provided adequate support in a timely and professional manner this milestone will be considered successfully completed.
• Implementation
A bill of materials for the construction of the unit must be written. These materials must then be ordered and assembled. Programming code must also be successfully installed to create a functioning unit. This milestone will be complete when all components are assembled or installed and functioning together.
• Testing
The circuit will be tested to ensure proper functionality over all possible conditions. The software will be re-tested to the extent that the operation of all the units together will be verified.
• Demonstration
The unit must be shown to operate acceptably in its final environment. This milestone will be complete upon placement of unit and verification of correct operation.
• Documentation
It will be necessary for all activities associated with the procurement and assembly of the circuit to be well documented for future reference. A formal assembly manual may be desired for outside parties to be able to complete a working replica of the implementation of this design. The software group will also document their advancement in software design and implementation resulting to the final software product. This milestone will be complete when a complete list of assembly tasks, materials, and procedures has been compiled and presented in a usable form.
Milestones will be evaluated after completion by each group member, as well as the faculty advisors. Below is a ranking scale standardizing the percentages by which evaluations will be completed. When considering the overall success of the project, the pie chart below demonstrates the emphasis put on each milestone. Although demonstration is the largest proportion, success will also be judged by what percentage of the project is completed and on what scale of accuracy and acceptance it was done so.
Table 1. Milestone Evaluation Ratings
|Exceeded |110% |
|Met |100% |
|Almost Met |90% |
|Partially Met |75% |
|Not Met |50% |
|Not Attempted |0% |
[pic]
Figure 1. Pie Chart for Weights of Milestones
2.12 Project Tracking Procedures
Completing the project on schedule, within budget and acceptably functioning is essential. A procedure for continual evaluation and reevaluation of the project’s status is needed. This procedure will include status reports, financial planning and reporting, and schedule evaluation.
• Weekly status reports, via email, will keep all team members, clients and advisors informed as to the current status, tasks, and upcoming schedules of the project. Financial resources used will also be included in these reports.
• Financial planning will include budgeting based on prices for all materials needed for completion of the circuit.
• Schedule evaluations will be performed regularly, consisting of a comparison with current schedule status and accomplishments with proposed schedule and Gantt charts. The current Gantt chart is located in Appendix A.
These procedures will allow for continual tracking of project status while not consuming resources, which could be applied to completing project tasks. Microsoft Project will serve as a tool for project schedule and resource management. If there is a case when, a team member is falling behind schedule in certain tasks, team leader and the rest of the team would provide assistance without straining too much on budget and labor costs. The member however responsible for not completing task in given time would justify their case or get a lower grade while evaluation. Every effort should be just to meet deadlines.
3 Statement of Work
This section details the specific tasks that the May06-18 project team will accomplish during the duration of this project.
Task 1 – Project Familiarization
Objective – The team will gain an understanding of the project through meetings with and documentation provided by the client.
Approach – All team members will read references provided by the client and sign up for the Isadora Yahoo group to better understand the functionality of the software. The client and advisors will be available to answer any questions posed by the team.
Expected results – The current team shall know the project well enough to start designing the product, support it after being installed and make continuous changes to produce better results.
Task 2 – Research for Transmitter/Receiver
Objective – The team will research the available transmitter/receiver units available in the market that can be used for the project.
Approach – Client has expressed concern about static induced in the input data while using the devices from past experiences. The static could be from the sensors due to heavy electromagnetic field on the stage from stage lights and electric equipments. The team will research off the shelf transmitter/receiver circuits that fit under budget and transmit the data most efficiently. In the event sufficient devices cannot be found, designs will be constructed and the transmitters and receivers will be constructed.
Expected results – Product with efficient data management and optimum circuit build.
[pic]
Figure 2. Anticipated Hardware Setup
Task 3 – Putting Hardware Together
Objective – After the hardware is found, team will design circuits and wiring that will minimize corrosion and make the equipment shock proof.
Approach – Assist client by learning how they want the equipment built so necessary changes can be made to the circuit to handle normal wear and tear.
Expected results – Durable and long lasting equipment.
Task 4 – Research of Isadora Software Development
Objective – The team will research Isadora software development.
Approach – Team members will have to familiarize themselves with the code and documentation provided with the Isadora Software Development Kit.
Expected results – During this test period, all bugs will be discovered and relayed to the team for removal. The team will continue to gain familiarity with the functions of the unit.
Task 5 – Testing of Software Environments
Objective – The May06-18 team will write specific test cases for the main functionalities (software end and customer end). This will help to produce the module for the software.
Approach – Specific test cases will need to be written covering all available functions for the module. These test cases will cover all the properties of operation (drag/drop function, establishing connection, etc.). The test cases will be split up among members and all test cases will be run at least twice.
Expected results – During this test period, all bugs will be discovered and relayed to the team for removal. The team will continue to gain familiarity with the functions of the unit.
Subtask 5.1 – Writing Test Cases
Objective – Create test cases that comprehensively test the capabilities of the software.
Approach – A test case will be written for each and every available function of the module, using the UML guide. This involves every action available through the interfaces on the front of the workspace (visibility, icon, connectivity, getting data as voltage from the sensors into the module).
Expected Results – An extensive list of test cases will provide direction to the testing and ensure that every function of the module is tested twice.
Subtask 5.2 – Executing Test Cases
Objective – Divide the testing among members of the team based on test cases so that two people will run every test case at least once. The tests must be run as soon as possible to allow for bug removal before deployment of unit.
Approach – Each test case will be assigned to two people. This will allow multiple runs of program tests should bugs be uncovered. Any fixes will be made after all function tests have been run. A second round of testing will verify that fixes have been made and have not affected the operation of other functions. Dancers are available to the team for testing and will be included to verify the acceptability and approval of all customers involved.
Expected results – All bugs will be discovered and resolved by the team. Retesting will occur after bugs have been fixed and will verify that module functions without error. Running tests will allow the team to continue to get familiar with the unit and its operation.
Task 6 – Documentation
Objective – Create extensive documentation for assembly of the hardware on the dancer, allowing the client to use the hardware to create more units in the future.
Approach – A parts list will first need to be created, then a cost estimate, assembly instructions for hardware and installation instructions for software.
Expected results – In the future, the client or other groups will be able to create multiple units using the described documentation.
Task 7 – Setting up the system for the client
Subtask 7.1 – Parts List
Objective – Compile a parts list of all parts in the current unit, including hardware and software.
Approach – Find product numbers and parts descriptions for all components of the unit. These part numbers will need to be checked on the Internet to ensure that all parts are easily accessible to future groups. It is very important that the equipment should fall well under budget.
The assembly instructions will assume in a well padded enclosure to avoid wear. Also, where available, the vendor for all parts will be recorded. The software used on the current unit will be documented along with what needs to be purchased and what the creator of the software provided.
Expected results – Future groups will be able to order exactly what is in the current unit based on the list described directly above.
Subtask 7.2 – Cost Estimate
Objective – Create an accurate cost estimate for creating the unit.
Approach – While compiling the parts list, prices for the components will be found. Any price breaks for bulk purchases will be recorded. Software that is required will also be recorded. After these prices have been tallied, a total parts cost can be created. The labor cost will be roughly estimated. This estimate will be revised during assembly of the unit during the spring semester.
Expected results – Co-Motion Dance Theatre and Iowa State Dance will have an accurate cost breakdown of the unit. The team will be able to provide a rough estimate of labor and subsequently cost of labor involved in assembling the unit.
Subtask 7.3 – Alternative Parts List
Objective – It may be necessary to have a list of parts that could serve as replacements for the current unit, should the current parts be unavailable. The
May06-18 group shall be responsible for creating this list of auxiliary and suitable replacement parts.
Approach – While searching for the current parts, any acceptable alternatives should be noted. The parts will have to be verified as backward compatible before being placed on a recommended alternative parts list. The prices of these parts will also be noted.
Expected results – A list of alternative parts shall be available to groups, should the parts in the current unit be unavailable.
Task 8 – Research of auxiliary technologies
Objective – The team will research any auxiliary technologies that may be brought forth by client, the advisors or the team itself.
Approach - This research will have a priority lower than that of building a second unit and supporting the first unit. Two technologies have already been suggested: wireless communication between units, and laptop integration.
Expected results – The team will provide documentation related to the auxiliary technologies for a future team to implement.
4 Estimated Resources and Scheduling
Completions of the this project is dependant on the managing of labor and item resources. Below, Table 5.1 breaks down the estimated hours each of the personnel will allocate to complete each of the tasks. Labor resources are assigned based on the specialty and education of the personnel.
Table 2. Personal Task Allocation
[pic]
Completion of the project hardware is dependent on acquiring the resources itemized in Table 5.2. Many of the more of expensive items have been donated to the project in various degrees of condition. As a result, Table 5.1 includes the cost per unit of the resources as a precaution if a replacement is needed. Additional information includes the items that would aid the project, but is not a technical necessity, such as an Isadora software license.
Table 3. Itemized Project Resources Needed
[pic]
As with any resource, there is an associated cost. Below, Table 5.3 displays the estimated cost of the project, itemized by resources. The table also factors in additional cost such as the cost of labor. These estimated project cost assumes best case in regards to the quality of donated items. In general, in calculating cost, the Table 5.3 replacement parts will not have to be ordered.
Table 4. Estimate, Itemized Cost of Resources
[pic]
To better manage these resources, a timeline is implemented to predict task outline and provide goals to keep the project on time. The Gantt chart below, figure 3, that outlines task deadlines and milestones that will ultimately guide the timing of the use of resources. To ensure adequate progress is, weekly progress reports will be made by all team members, detailing specific successes and problems encountered over the past week. Such information will be reviewable by all members of the team. It will be up to the team’s digression as to determining if adequate progress is being made by each individual.
[pic]
Figure 3. Timeline, Dependencies, and Breakdowns of Tasks
Judgement regarding adequate progress is based on the ability of reaching the designated milestones where the associated deliverables are due. The “Implementation Milestone” will result in a design document and indicates the final phase before hardware and software implementations begin. A working beta of the project will be deliverable for the “Testing Milestone,” with the final project demonstration deliverable by the “Demonstration Milestone.” The project documentation should be completed by the “Documentation Millestone.”
5 Project Team Information
Client Information:
Baker, Janice
Director, Iowa State Dance (Dept. of HPP)
|Campus Address: |240 Forker Building |
| |Ames, IA 50011 |
|Home Address: |2914 E. Sheridan Ave. |
| |Des Moines, IA 50317 |
|Office Phone: |(515) 294 - 3047 |
|Fax: |(515) 294 - 8740 |
|Email: |mover@iastate.edu |
Valerie Williams
Co-Motion Dance Company
|Home Address: |129 East 7th |
| |Ames, IA 50010 |
|Office Phone: |(515) 232-7374 |
|Email: |v@ |
Faculty Advisor Information:
Dickerson, Julie
Electrical and Computer Engineering Associate Professor
|Campus Address: |3123 Coover |
| |Ames, IA 50011 |
|Home Address: |4116 Purvis Ln. |
| |Ames, IA 50010 |
|Office Phone: |(515) 294 - 7705 |
|Fax: |(515) 294 - 8432 |
|Email: |julied@iastate.edu |
Sheble, Gerald
Electrical and Computer Engineering Professor
|Campus Address: |1115 Coover Ames, IA 50011 |
|Home Address: |3442 Southdale Dr. Ames, IA 50010 |
|Office Phone: |(515) 294 - 3046 |
|Fax: |(515) 294 - 4263 |
|Email: |gsheble@iastate.edu |
Team Member Information
Bhatia, Tarun
Computer Engineering
|Univ. Address: |3110 West Street |
| |Ames, IA 50014 |
|Phone: |(515) 450 - 8102 |
|Email: |tarunb@iastate.edu |
Farniok, Amanda
Electrical Engineering
|Univ. Address: |204 Jewel Dr. #2 |
| |Ames, IA 50010 |
|Phone: |(612) 210 - 2453 |
|Email: |afarniok@iastate.edu |
Ly, Sheng Chang
Computer Engineering
|Univ. Address: |111 N Sheldon Ave #1 |
| |Ames, IA 50014 |
|Phone: |(712) 254 – 0310 |
|Email: |macli@iastate.edu |
Sills, Alexander
Electrical Engineering
|Univ. Address: |119 N Hyland Ave #3 |
| |Ames, IA 50014 |
|Phone: |(515) 451 – 5383 |
|Email: |yznacnac@iastate.edu |
5.1 Closing Summary
Interactive dance has opportunities available for innovation, creativity, and technological ingenuity. Through the use of sensors located on the body, dancers will be able to control their surroundings regarding light, video, and sound. Building off the information presented to the team from the client, advisors, and past experimenters, a product will be developed entailing easy use, accuracy, and capability for expansion. Considerations for the customer will continuously be valued high while pursuing this project.
Investigation into previously used devices will be the first task to evaluate the effectiveness of the materials and alterations that need to be made. Theaters will be toured and measured for noise with a spectrum analyzer. Experimentations will be done involving Isadora, transmitters, receivers, and sensors once a scheme has been planned out. Cost considerations and part alternatives will be evaluated for the final design. A beta version will be tested and released for use during a performance in March 2006. Full documentation will be completed and updated throughout the duration of the project and available to all individuals involved with the project at all times via a website.
Under completion, dance performances will be able to be produced using the dancers and one computer, reducing the precision necessary during a performance and eliminating several back-stage people. Creativity can be at an optimum level, and all people involved will be a part of the leading technology in the theater world. Opportunities for visual and audio variations and experimentation will lead to enhanced performances. Technology is moving into the theatrical world, and with this project, we will be in the leaders of development and implementation of computer controlled theater complonents.
5.2 References
Course textbooks previously used will be used when considering technical aspects of the project.
• Microelectronic Circuits Adel Sedra, Kenneth Smith. Fourth Edition 1998.
• Signal Processing First James McClellan. Pearson Prentice Hall 2003.
The following websites have been reviewed and will be accessed throughout the duration of the project. Thus far, they have only been viewed and not used in any documentation.
• Troika Tronix Website
• Yahoo group dedicated to users and developers of Isadora
• Royal Academy of Dance, DIEM Digital Dance System
• Gertrude Stein Repertory Theatre
• Bradley Newman, DIEM Digital Dance System
• Flex Sensor design
• Hal Eager
• I-CubeX Wi-miniSystem
• Performances using Isadora
• MICI Connections
• MIDI Cables
• MIDI Software Development Tools
The following websites are being used for investigating transmitters and receivers.
•
•
•
•
Several contacts will also be consulted throughout the duration of the project. The following is a list of persons proposed to be informational resources:
• Jason Boyd: Product packaging contact
• Brian Swanson: Fischer Theater contact
• Mike King: City Auditorium contact (515)239-5365.
• Steve Harder: Stephens Auditorium contact
-----------------------
Research and
Familiarizion
8%
Implementation
23%
Testing
15%
Demonstration
39%
Documentation
15%
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.