Computer Control of Theater Performance Electronics
Design Report
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: November 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.
ii Table of Contents 1 Project Overview...... 1 1.1 Executive Summary...... 1 1.2 Acknowledgement...... 2 1.3 Problem Statement...... 2 1.3.1 General Problem Statement...... 2 1.3.2 General Solution Approach...... 2 1.4 Operating Environment...... 3 1.5 Intended Users and Intended Uses...... 3 1.5.1 Intended Users...... 3 1.5.2 Intended Uses...... 3 1.6 Assumptions and Limitations...... 4 1.6.1 Updated Assumptions List...... 4 1.6.2 Updated Limitations List...... 4 1.7 Expected End Product and Other Deliverables...... 4 1.7.1 End Product Deliverables...... 4 1.7.2 Documentation...... 5 2 Approach and Product Design Results...... 5 2.1 Approach Used...... 5 2.1.1 Design Objectives...... 5 2.1.2 Functional Requirements...... 5 2.1.3 Design Constraints...... 7 2.1.4 Technical Approach Considerations and Results...... 8 2.1.5 Testing Requirements Considerations...... 8 2.1.6 Recommendations for Project Continuation...... 9 2.2 Detailed Design...... 9 2.2.1 Hardware Design...... 9 2.2.2 Software Design...... 13 2.3 Proposed Milestones and Evaluation Criteria...... 15 2.4 Project Tracking Procedures...... 17 3 Estimated Resources and Scheduling...... 18 4 Project Team Information...... 22 4.1 Client Information:...... 22 4.2 Faculty Advisor Information:...... 23 4.3 Team Member Information...... 24 4.4 Closing Summary...... 25 4.5 References...... 26 Appendix A Statement of Work...... 28
i List of Tables Table 1. Milestone Evaluation Ratings...... 16 Table 2. Personal Task Allocation...... 18 Table 3. Updated Task Allocations...... 18 Table 4. Itemized Project Resources Needed...... 19 Table 5. Estimate, Itemized Cost of Resources...... 20
ii List of Figures Figure 1. Abrams/Gentile Entertainment Flex Sensor Diagram...... 10 Figure 2. Circuit Setup for Flex Sensor...... 10 Figure 3. Impedance Buffer Setup...... 11 Figure 4. Overview of Setup between Nodes and Receivers...... 12 Figure 5. Crossbow Components to be used: MDA300, MPR2400, MIB510...... 12 Figure 6. Primary flow of Actor functions...... 13 Figure 7. UML class diagram for Isadora Actor...... 14 Figure 8. UML Sequence Diagram...... 14 Figure 9. Actor Setup after Initial Parameters Setup...... 15 Figure 10. Demonstration of Two Actors Linking Together...... 15 Figure 11. Pie Chart for Weights of Milestones...... 17 Figure 12. Timeline, Dependencies, and Breakdowns of Tasks...... 21
iii 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. Actor – Module for Isadora software developed as an end product. Scene – A collection of user grouped actors in Isadora.
iv 1 Project Overview 1.1 Executive Summary 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. With the innovations developed, technology will meet theater to create illusions and expand the ingenuity of the show. To be competitive in the theatrical world and aid the advancement of others within the field, this project will keep Iowa State Dance and Co-Motion Dance Company ahead of others and gain respect of other companies throughout the United States. There are two components of this project which have been divided between project team members based on education and interest. Hardware and software are the two different aspects into which the design has been divided. Each will correspond with the other to assure a smooth integration further along in the project plan. Hardware team members are in charge of all hardware to be used in the project. This includes flex sensors, transmitters, receivers, wiring, circuit design, and other similar components. Careful planning and testing will be implemented to assure purchased materials will not be damaged when implementation is applied. Software team members will learn how Isadora corresponds with the drivers and use this to create a program to intake the signals sent to the computer and manipulate the data for use by the performance environment controls. Experimental hardware will be used to test the expected outcomes of the setup. Both teams will then be able to work together to make the equipment work with the software created. Variations can then be made as necessary to the hardware prior to implementation of the purchased products to avoid destruction. 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. Physically, the transmitters will be compact and durable and resistant to wear. Enclosed, the batteries will need to be able to be easily changed, and an easy access on/off switch will be in place. The signals will be accessed through the Isadora program for use as currently set up in the program. Cost for the project may hold a wide range of costs. Dependent upon who is to fund the project, alterations in the expected order of supplies may change. If the devices are to be used for lab purposes, a kit from the manufacturer may be ordered to supply enough for groups to use. Purchasing a kit will provide a variety of the components needed to complete the project. However, if funding is to be provided by the customer, this kit may also be an option for the future innovations of the project. Cost efficiency will play a large role in whether individual components or a package will be purchased.
1 Project end will be May 6, 2006. At this point, all documentation and products will be delivered to the client. A beta version of the product is to be potentially produced by the middle of February for use in a performance in March. Dancers will need to proof the setup and determine any bugs undetected prior to release, and inform the developers of any functionality that is not included with the setup provided. 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. The design team would also like to acknowledge the assistance of Jason Boyd, the ECpE departmental technician. Jason has and will be helping with design ideas and more specifically assisting with packaging of the end product. Dr. David Stephenson will also be offering assistance when his input is pertinent and he is available. 1.3 Problem Statement 1.3.1 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. The flex sensors alone will operate on this apparatus and other means of sensor input will be transmitted using other pre-existing means. 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. 1.3.2 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. Wires connecting the sensors to the transmitter will also need to be contained and kept away from disturbances. A large milestone in the project has been finding a transmitter/receiver apparatus that works well and also has the capability for expansion to receive multiple transmitters. The receiver will be set up to send input to the Isadora computer through a USB connection. 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. Interchangeability of batteries and sensors was a consideration when choosing hardware for the project. A sensor watcher program in C code will be designed in Isadora to take the transmitted sensor input and use it effectively to manipulate the stage environment.
2 1.4 Operating Environment The end product will be used extensively in theatrical dance settings such as the Betty Toman Dance Studio in Forker Hall, 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. Research was 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 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 1.5.1 Intended Users The end product will be designed for use 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. 1.5.2 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 expansive, impact-prone, or otherwise hazardous than that of a dance performance.
3 1.6 Assumptions and Limitations 1.6.1 Updated 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 apparatus will be used for flex sensor data transmission only. 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. This project will not be attainable for under the $150 nominal senior design project budget. The proposed design will be one that will assuredly work, as opposed to a minimum cost option. The design team will attempt to acquire the excess funds through the client or through the department of electrical and computer engineering at Iowa State. All programming and documentation will be completed in English, as all products are targeted for United States citizens who primarily speak English. 1.6.2 Updated 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 sensors used now are satisfactory and will be used. The end product will be only one transmitter/receiver pair but will allow for expansion for up to four transmitters. The end product must be small and compactly packaged to allow for full range of motion by the user. The end product must be safe and protect the end user from shock or harm. 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 1.7.1 End Product Deliverables All end product deliverables will be provided to the clients by the 2nd Week of February 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. 4 1.7.2 Documentation Deadline for all documentation corresponding to this project is due May 6, 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 Approach and Product Design Results This section shall outline the planned methods investigated for completing the project as well as detailing the method selected for implementation. It will include an approach for building hardware components and a software module that reads the flex sensors as inputs which manipulates the video and lighting in Isadora. 2.1 Approach Used This section details the different options considered in our design and research. The design objectives reiterate the requirements of the project. Advantages and disadvantages of each option are revealed and our final approach shows dominance over the other options. 2.1.1 Design Objectives The following objectives are designed around the problem statement to ensure the project meets the requirement of the client: Devise a compact, durable apparatus to wirelessly transmit four flex sensor signals per dancer with the capacity to have four dancers. The design team will fabricate one of these dancer apparatuses and allow for expansion for three more apparatuses. The documentation shall guide the end-user and enable them to replicate the apparatus. Actor for Isadora will provide two outputs. The first output would be a triggered based threshold output. This output would trigger a bridged actor to a sleep/active mode. The second output would be a normalized scaled value The value is based on the degree of the flex in the flex sensor, which ranges from 0 to 127. This value is translated by the actor to fall into a defined range. This translated output may serve as an input to other modules. 2.1.2 Functional Requirements Within the following sections, various aspects of the functionality of the project are described, corresponding to both the general project and specific software applications.
5 2.1.2.1 General Functional Overview 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 a laptop and each sensor to the transmitter. Hardware should allow for expansion of four transmitters, each with four sensors. Additional Requirements The module should be coded such that it could support four transmitters if so desired. Designing Serial Connection through TinyOS TinyOS should be used to connect a driver to Isadora that would transmit data. The software TinyOS provides interface between hardware and software for the project. 2.1.2.2. Functional Requirement Overview The following is an overview of the functions that will be provided by the software: • Software Level Definition: CreateActor Function that instantiates the actor in Isadora ReceiveMessage Function to listen to the input stream from the hardware DisposeActor Function that destroys the actor when deleted, scene is closed, or actor is cut GetParameterString Function for getting the description of the input out parameters from Isadora ActivateActor Function that sets the activate flag depending if the actor’s scene is activated HandledPropertyChangeValue Function called when an input parameter value is changed to update the actor GetActorDefinedArea Function that gets the area needed to draw the actor in Isadora DrawActorDefinedArea Function called when actor is required to be drawn in Isadora GetActorInfo Function that gets the actor’s class, id, and pointers to all the actor’s functions
6 2.1.3 Design Constraints 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 and transmitters 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. The software shall run on Windows and Macintosh computers. Client and faculty advisors use two different, incompatible systems, and the software must be designed to run on both systems. The saved collections shall be compatible with all versions of the software. The Windows version of the software shall be able to load collections created on Macintosh systems. The software shall be produced within two semesters. The development team only has two semesters to complete the design, implementation, and testing of the software. Future senior design teams can complete additional work on the project if the client or faculty advisors need additional functionality. The ISADORA Standard Edition needs to be installed on the system. The actor will need the ISADORA installed to run. This user will need to install this. The installer for the collection software may provide a link to the ISADORA homepage where users can download the required software. Additional Software Requirements The standard coding platform being Macintosh might hinder understanding coding architecture for Isadora software. It might also burden producing a testing version for the module in Windows platform. The software has to be able to read the sensor inputs in voltage and convert it to a form Isadora recognizes. Connectivity Requirements The system must communicate exclusively over a standard laptop.
7 2.1.4 Technical Approach Considerations and Results 1. Hardware Approaches a. Analog Audio Channel Transmitters i. Advantages – Very efficient in transmitting analog signals in an audible bandwidth. Good range. Satisfactory consideration for multiple transmitters. ii. Disadvantages – Not good for data transmission. Could not have multiple channels from a single transmitter. Bandwidth not suitable for analog data signals. Interference possible. b. Analog to Digital (serial) Conversion on Dancer, Serial Port Transmitters i. Advantages – Viable for data transmission. Range acceptable. Power consumption low. ii. Disadvantages – Bulky and heavy apparatus. Lots of debugging issues away from the computer software. c. Industrial Grade Data Transmission i. Advantages – Very good for analog data transmission. Excellent range. Interference issues resolved due to frequency hopping and discrete channels and non-competition with noise found in environment. ii. Disadvantages – Too large for compact packaging. Sampling/data rate too slow for dance implementation. Not enough data channels available per transmitter. d. Wireless Data Acquisition Mote Technology i. Advantages – Designed for transmission of multiple types of data signals. Operates on 2.4 GHz frequency range with 802.15.4 compliance for multiple discrete data channels. Small packaging. Easily changeable batteries. Ease of programming and debugging. Range above requirements. Strong prospects for future sensor innovations. ii. Disadvantages – High cost. Serial to USB converter needed to meet all design requirements. Windows only functionality. Possible limitation on number of analog inputs. iii. This technology was selected because it most completely met the requirements mandated in the problem statement. 2.1.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 Several testing procedures will need to occur throughout the development of the project. Testing of the flex sensors will also need to be completed to assure accurate resistances are being applied. Using the setup of the voltages in and 8 the impedance buffer, multimeters will be used to test voltages and resistances before being attached to the MICAz instrument. Trials will be run with testing models of the MICAz model to fully comprehend how the signal will be transmitted. This will provide further information on how the signal will deviate from expected with distance and line-of-sight as well as assure there are no unanticipated interferences. Alterations to the code or equipment setup can then be adjusted to compensate for any deviations from expected outcomes. Durability testing will also be completed. Testing of the cases for the instruments will undergo moisture and wearing tests. This will be completed prior to insertion of the electrical components. Applying moisture to the casing and inspecting for moisture inside as well as effects of the casing itself will be conducted vigorously to ensure the components to be inserted will not be effected during use. Software Testing The team will develop a test plan to formalize and track all software testing and bugs. The test plan will define the functional and non-functional tests. The functional testing will be automated so regression testing can be performed after revisions to the software. Each of the functional requirements shall have one or more automated tests associated with it. All features of the program must be tested through either automated testing or human testing. Since no actor development code has been written yet, test plan will be formulated while the code for ISADORA module is written. 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.1.6 Recommendations for Project Continuation This project in the future could have sound as an input. Sound could be added by using Piezo sensors and microphones for each dancer. A new circuit board would be needed to perform audio detection which could increase the cost of the final project. Pressure, temperature, and accelerometer technology sensors can also be implemented using a different hardware design. 2.2 Detailed Design 2.2.1 Hardware Design This section will begin describing the hardware design at the dancer interface level and work towards the computer interface level. Each aspect of the hardware will be described in terms of its connection, cost, and functionality in the overall scheme.
Each dancer will be able to wear four flex sensors, all of which can be operated by a single transmitter. Abrams/Gentile Entertainment Flex sensors are distributed by a variety of companies at prices ranging from $7 to $12 per sensor. These can be ordered from Images SI Inc. at www.imagesco.com. As the sensor bends, the resistance ranges from 10k to approximately 35k, depending on the angle of the bend, which will cause
9 a change in the voltage output of a simple analog impedance buffer circuit. A diagram of the flex sensor and description of its operation are shown below in Figure 1.
Figure 1. Abrams/Gentile Entertainment Flex Sensor Diagram One lead of the flex sensor will be soldered to an input voltage of 5.0 volts, supplied by the excitation voltage of the MDA300, via appropriate gauge coated wire, while the other is connected using the same wire to the input of an impedance buffer, as shown in the setup of Figure 2. Using the resistance of the flex sensor and an additional resistor valued at 10k, a voltage divider is created. The negative and positive power supply voltages to the op amps will be 0 and 2.5 volts respectively. Wire and solder for this portion has already been acquired from past projects, so cost is negligible.
Figure 2. Circuit Setup for Flex Sensor The output of the impedance buffer, made up of a National Semiconductor LMC660, containing four operational amplifiers per chip, will provide the sensor board with a clear and steady signal ranging from 1 V to 2.5 V. A setup of the buffer circuit is shown below in Figure 3. Four input terminals are required for the four input signals from the sensors to be used. Through National Semiconductor, these can be purchased in quantities
10 greater than 1000 for a cost of about $0.80 per amplifier. For purposes of this project, samples of the product will be ordered from the manufacturer or taken from previous supplies provided.
Figure 3. Impedance Buffer Setup The reason for using the impedance buffer instead of a simple voltage divider is to make sure that the output voltage does not exceed 2.5 volts. This is a limit for the input of the sensor board set by the manufacturer. The sensor board to be used is the MDA300, Environmental Monitoring Board, manufactured and sold by Crossbow Technologies Inc. at a cost of $250 per board. Using similar coated wires as before, the outputs of the impedance buffers are hardwired to the sensor board via simple screw terminals. Once the voltage has entered the sensor board, it will be sent to the MICAz MPR2400 through a 51-pin expansion connector. As with the MDA300, Crossbow distributes the MPR2400 at a price of $125. The MDA300 and MICAz have complimentary male/female 51-pin connectors for this part of the setup. From here, the digital signal will be sent at 2.4 GHz at a rate of 250 kbps to the computer interface part of the hardware.
11 Figure 4. Overview of Setup between Nodes and Receivers
Figure 5. Crossbow Components to be used: MDA300, MPR2400, MIB510 When reaching the computer setup, each transmitter will have its own discrete channel to be read and interpreted. Once the signal travels to the receiving end, it will be accepted by another MICAz, which will be connected to the input of a serial interface board called an MIB510, which costs $90 from Crossbow. The MICAz and MIB510 also have complimentary male/female 51-pin connectors to facilitate this part of the setup. In Figure 4, the idea described is depicted: at the nodes, there is a sensor and data acquisition board (MDA300) connected to a radio board (MICAz) which then transmits the signal to the receiving end, which is taken in by a radio board (another MICAz) which sends the data to the serial interface board (MIB510). TinyOS software will be used to program the hardware modules, interpret the signal at the serial interface, and export data for use in the Isadora system. Packaging, to be customized out of plastic cases, will be designed for the multiple parts of the apparatus. Specifically, the dancer worn components will need to be secured to each other and to the dancer to avoid loss of parts and functionality. They will also be insulated sufficiently to protect the components from environmental factors such as shock, moisture, and g-forces.
12 2.2.2 Software Design This section will begin describing the software design at the computer interface level and work towards the hardware/dancer interface level. Each aspect of the software will be described in terms of its software code, cost, and functionality in the overall scheme. Software code in Isadora software development kit for Macintosh computers will be written to design a sensor-watcher actor. This actor will be able to read continuous flow of data being send from the flex sensors connected to the USB port via a transmitter- receiver circuit. The following flowchart, Figure 6, provides the primary steps and function calls performed by the actor. At first, the user instantiates the actor in Isadora. That is done through the CreateActor() function. At this time the user will supply any necessary inputs. If the actor is deleted at any time the DisposeActor() function is called to properly remove the actor. Secondly, Isadora will check if the current actor is in the present scene. If it is, the function ActivateActor() with a “true” parameter is passed so the actor knows to begin executing its primary code. In this case, the primary data is received through the function, ReceiveMessage(). This function is responsible for the reading the stream and assigning the proper outputs. Of course the if the actor is not in the scene, or the scene changes to one in which the current actor is not a member, the actor’s ActivateActor () function is called with a “false” parameter to prevent the actor from executing.
Figure 6. Primary flow of Actor functions
13 Following is an UML class diagram, Figure 7, for any actor developed within Isadora SDK. The variables like sensorInput contain the values that can be used for various functionalities described for any actor within Isadora.
Figure 7. UML class diagram for Isadora Actor The UML Sequence Diagram here, Figure 8, predicts the variables that need to be initialized at the time of actor creation. The ioActorInfo is a pointer to the newly created Actor when we initialize it with a kActorName class object. The inActive Boolean type input sets the actor to trigger on off in the scene. The outTopAreaWidth and outTopAreaMinheight variables set up the size and the height of the actor in the scene. Below is the mockup of an actor after its initial parameters setup.
Figure 8. UML Sequence Diagram
14 Figure 9, below, is a mock up of the anticipated user interface for the actor within Isadora. The user provides inputs or actor connections to the inputs on the left. The outputs of the actor are on the right, which may be connected to other actors.
Figure 9. Actor Setup after Initial Parameters Setup Below, Figure 10 illustrates how two actors can be connected. For instance, a mouse – watcher (mouse sensor watcher), can be connected to the motion blur actor already available in Isadora to manipulate the blurriness in the video feed from an external camera.
Figure 10. Demonstration of Two Actors Linking Together 2.3 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.
15 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%
16 Research and Familiarizion Documentation 8% 15%
Implementation 23%
Demonstration 39% Testing 15%
Figure 11. Pie Chart for Weights of Milestones
2.4 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.
17 3 Estimated Resources and Scheduling Completions of this project is dependant on the managing of labor and item resources. Below, Table 2 breaks down the initial 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 Original Personnel Resource Allocation Estimates Tasks 2. Research 4. Research of 7. Setting 1. Project 3. Putting 5. Testing of 8. Research for Isadora 6. Under- Up the Familiar- Hardware Software of Auxiliary Transmitter/ Software standing System for ization Together Environments Technologies Receiver Development the Client Personnel Totals Bhatia, Tarun 34 10 5 40 60 15 2 5 171 Farniok, Amanda 20 30 50 5 20 14 6 7 152 Ly, Sheng 23 4 4 32 63 13 3 3 145 Sills, Alex 21 35 45 6 25 13 6 8 159 Totals 98 79 104 83 168 55 17 23 627
These initial estimates needed to be modified as more knowledge was gained. Project Familiarization, task one, took much less time than expected due to the relative simple concept of the project’s scope. While the concept is simple, implementation and research took longer than expected. Many technologies were considered in determining the appropriated hardware for the transmitter and receiver. This added a significant time to task 2 as well as task 4 where the software interface for the hardware needed to be considered as well. Table 3. Updated Task Allocations
Updated Personnel Resource Allocations Tasks 2. Research 4. Research of 7. Setting 1. Project 3. Putting 5. Testing of 8. Research for Isadora 6. Under- Up the Familiar- Hardware Software of Auxiliary Transmitter/ Software standing System for ization Together Environments Technologies Receiver Development the Client Personnel Totals Bhatia, Tarun 15 2 5 50 60 15 2 5 154 Farniok, Amanda 5 45 53 5 20 14 6 7 155 Ly, Sheng 10 3 4 42 63 13 3 3 141 Sills, Alex 5 40 48 4 25 13 6 8 149 Totals 35 90 110 101 168 55 17 23 599
Completion of the project hardware is dependent on acquiring the resources itemized in Table 4. Many of the more of expensive items have been donated to the project in various degrees of condition. As a result, Table 5 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.
18 Table 4. Itemized Project Resources Needed
As with any resource, there is an associated cost. Below, Table 5 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, the calculated costs in Table 5 do not include any replacement parts that may need to be ordered.
19 Table 5. Estimate, Itemized Cost of Resources
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 12, that outlines task deadlines and milestones that will ultimately guide the timing of the use of resources. Descriptions of all tasks can be found in Appendix A at the end of this document. 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 able to be reviewed 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.
20 Figure 12. 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.” In general, both the hardware and software research are done concurrently. The initial schedule had this task scheduled to be done by the end of October. The actual result has slipped just a week to allow for further research in hardware alternatives. For the same reason, the software research took longer than expected as more time was spent considering what software would be required to interface with the hardware. The implementation task is on schedule with a notable change in the deadline for a working beta. Per the client’s request, time of the working beta is in mid February as opposed to early March. At this time, work regarding documentation and client setup will also begin.
21 4 Project Team Information Information regarding the project documents and information can be found on the Senior Design website at http://seniord.ece.iastate.edu/may0618/. 4.1 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: [email protected] Valerie Williams Co-Motion Dance Company Home Address: 129 East 7th Ames, IA 50010 Office Phone: (515) 232-7374 Email: [email protected]
22 4.2 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: [email protected]
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: [email protected]
23 4.3 Team Member Information Bhatia, Tarun Computer Engineering Univ. Address: 3110 West Street Ames, IA 50014 Phone: (515) 450 - 8102 Email: [email protected]
Farniok, Amanda Electrical Engineering Univ. Address: 204 Jewel Dr. #2 Ames, IA 50010 Phone: (612) 210 - 2453 Email: [email protected]
Ly, Sheng Chang Computer Engineering Univ. Address: 111 N Sheldon Ave #1 Ames, IA 50014 Phone: (712) 254 – 0310 Email: [email protected]
Sills, Alexander Electrical Engineering Univ. Address: 119 N Hyland Ave #3 Ames, IA 50014 Phone: (515) 451 – 5383 Email: [email protected]
24 4.4 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 components.
25 4.5 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. These have either been used for brief information regarding various aspects of the project, or used as a main reference in certain areas. Troika Tronix Website http://www.troikatronix.com/links.html Yahoo group dedicated to users and developers of Isadora http://groups.yahoo.com/group/isadora-user-group/ Royal Academy of Dance, DIEM Digital Dance System http://www.musik-kons.dk/english/diem/digdance/index.php Gertrude Stein Repertory Theatre http://www.gertstein.org/people.html Bradley Newman, DIEM Digital Dance System http://interactive.usc.edu/members/bnewman/archives/001007.html Flex Sensor design http://devices.sapp.org/component/flex/ Hal Eager http://www.haleagar.com/ I-CubeX Wi-miniSystem http://infusionsystems.com/catalog/product_info.php/cPath/21/products_id/98 Performances using Isadora http://www.troikaranch.org/wrk/surfacing.html MICI Connections http://music.northwestern.edu/links/projects/midi/pages/mdcnctjv.html http://www.borg.com/~jglatt/tutr/connect.htm http://midiworld.com/ MIDI Cables http://www.ramelectronics.net/html/midi_cables.html MIDI Software Development Tools http://www.harmony-central.com/MIDI/dev.html The following websites are being used for investigating transmitters and receivers. Crossbow Technology Inc. www.xbow.com Honeywell www.honeywell.com
26 Johnson Controls www.johnsoncontrols.com www.musiciansfriend.com www.Americanmusicsupply.com www.music123.com www.zzounds.com Several contacts will also be consulted throughout the duration of the project. The following is a list of persons proposed to be informational resources: Dr. David Stephenson: General assistance Jason Boyd: Product packaging contact Brian Swanson: Fischer Theater contact Mike King: City Auditorium contact (515) 239-5365. Steve Harder: Stephens Auditorium contact
27 Appendix A 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. 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.
28 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.
29 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.
30