Mechanical Structures Interactive Laboratory
by
Torrey Owen Radclie
S. B., Aeronautics and Astronautics, Massachusetts Institute of Technology, Cambridge,
Massachusetts (1997)
Submitted to the Department of Aeronautics and Astronautics
in partial fulllment of the requirements for the degree of
MASTER OF SCIENCE IN AERONAUTICS AND ASTRONAUTICS
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
January 2002
c Massachusetts Institute of Technology 2002. All rights reserved.
Author
Certied by
Accepted by
Department of Aeronautics and Astronautics
January, 2002
Carlos E. S. Cesnik
Visiting Associate Professor of Aeronautics and Astronautics
Thesis Supervisor
Wallace VanderVelde
Chairman, Department Committee on Graduate Students
2
Mechanical Structures Interactive Laboratory
by
Torrey Owen Radclie
Submitted to the Department of Aeronautics and Astronautics
on January, 2002, in partial fulllment of the
requirements for the degree of
Master of Science in Aeronautics and Astronautics
Abstract
The Mechanical Structures Interactive Lab is one of a number of new remotely accessible
WebLabs being developed at the Massachusetts Institute of Technology. WebLabs allow
students access to physical experiments from anywhere at anytime via the World Wide
Web. While these cannot replace laboratories that are more traditional, they facilitate lab
assignments when traditional labs are not practical. The Mechanical Structures Interactive
Laboratory is a framework for allowing remote experimentation on elastic structures. Users
of the system are able to obtain data from experiments they perform on the structures form
a remote location. The system is designed to allow new experiments to be easily added,
and can support all levels of mechanical structures courses currently oered at MIT. The
system can be used by multiple courses in multiple departments of multiple universities.
Users are only required to have a computer connected to the World Wide Web and they
can send actuator commands and monitor sensor responses in near real time. The typical
student is expected to spend between fteen minutes to an hour using the system to obtain
experimental data. A queuing system regulates (and allows monitoring of) system usage.
All of the software was developed using National Instruments G language. Unlike similar
systems, the Mechanical Structures Interactive Lab does not use any sort of Java based
applications. The system has been tested in a small graduate course. The students used a
piezoelectric actuator to stimulate a beam and monitored the response using strain gauges,
laser displacement sensors and a webcam. By using the same computer to both model the
beam and perform experiments, the students received rapid feedback on the accuracy of
their numerical models. While most of the feedback received was positive, there are still
a number of areas for system improvement. While work is still being done to make these
improvements, the system has shown itself to be an eective means of providing a positive
educational experience to engineering students.
Thesis Supervisor: Carlos E. S. Cesnik
Title: Visiting Associate Professor of Aeronautics and Astronautics
Acknowledgments
There are many people who I wish to thank for their help and support which made this
possible. First, I would like to thank my advisor, Professor Carlos Cesnik, who provided me
with this opportunity. Without his guidance none of this would have been possible.
I would like to thank the Microsoft Corp. through the I-Campus project for their support
for this project. I also wish to mention all the help I received from Jesus del Alamo and the
rest of the people at MIT working on WebLabs. And of course the help form the technical
support sta of National Instruments.
My room-mates Matthew Congo and Nicole Krumrei have always been there to help me
take my mind o of my work and to read through some of the early drafts of this work. I
also need to show my appreciation for all the support and encouragement I received from
Andrea Green over the years.
Finally I would like to thank Paul, Alex, Cyndi and Victoria who provided the extra
hands when they were needed.
Contents
Abstract
1
Acknowledgments
3
1 Introduction
13
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2 Current Work in Educational Remote Laboratories
17
2.1 MIT Microelectronics WebLab . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.2 Other I-Lab Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.3 MSI-Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3 System Layout
23
3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1.1 Mechanical Testing Structures . . . . . . . . . . . . . . . . . . . . . .
25
3.1.2 Actuation Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.1.3 Sensor Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2 Laboratory Controlling Software . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.3 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.3.1 Site Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.3.2 Matlab scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.3.3 CGI Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5
4 Platform Test
41
4.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.2 Student Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.3 Usage and Performance Data . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.3.1 Student Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.4 Laboratory Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.5 Student Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.6 Discussion of the Results and Needed Improvements . . . . . . . . . . . . . .
46
5 Conclusion
49
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.2 Successful Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
Bibliography
53
A Example Laboratories
55
A.1 16.010-16.040 - Unied Engineering . . . . . . . . . . . . . . . . . . . . . . .
55
A.1.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
A.1.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
A.1.3 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
A.2 16.20 - Structural Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
A.2.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
A.2.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
A.2.3 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
A.3 16.21 - Techniques for Structural Analysis and Design . . . . . . . . . . . . .
57
A.3.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
A.3.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
A.3.3 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
A.4 16.221 - Structural Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . .
58
A.4.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
6
A.4.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
A.4.3 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
A.5 16.222 - Mechanics of Filamentary Composite Materials . . . . . . . . . . . .
59
A.5.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
A.5.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
A.5.3 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
A.6 16.241 Advanced Structural Dynamics . . . . . . . . . . . . . . . . . . . . .
59
A.6.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
A.6.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
A.6.3 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
A.7 16.242 - Aeroelasticity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
A.7.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
A.7.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
A.7.3 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
B Sample Lab Assignment
63
B.1 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
B.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
B.2.1 Matlab script used for question 1 . . . . . . . . . . . . . . . . . . . .
71
C Code
75
C.1 Matlab Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
C.1.1 dataload.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
C.1.2 spectral.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
C.2 HTML les . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
C.2.1 Queue HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
C.2.2 Structure control HTML . . . . . . . . . . . . . . . . . . . . . . . . .
77
C.2.3 Data le save HTML . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
7
8
List of Figures
3-1 System Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3-2 Hardware Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3-3 Strain gauges mounted on steel beam . . . . . . . . . . . . . . . . . . . . . .
28
3-4 Block Diagram of structure controlling VI . . . . . . . . . . . . . . . . . . .
30
3-5 Layout of web site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3-6 Control web page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3-7 CGI application control scheme . . . . . . . . . . . . . . . . . . . . . . . . .
36
3-8 Block Diagram of typical VI control application . . . . . . . . . . . . . . . .
37
3-9 Block Diagram of queueing application . . . . . . . . . . . . . . . . . . . . .
39
4-1 Diagram of Beam Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4-2 Number of users per hour which accessed the beam controls during class assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
B-1 Diagram of Beam Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
B-2 First three beam modes found using 20 elements . . . . . . . . . . . . . . . .
68
B-3 Spectral analysis of beam response . . . . . . . . . . . . . . . . . . . . . . .
69
B-4 Strain gauge response to 5.3 Hz, 200 V piezo input . . . . . . . . . . . . . .
70
B-5 Strain gauge response to 32 Hz, 200 V piezo input . . . . . . . . . . . . . . .
71
B-6 Strain gauge response to 90 Hz, 200 V piezo input . . . . . . . . . . . . . . .
72
B-7 Plots used to determine system nonlinearity . . . . . . . . . . . . . . . . . .
73
9
10
List of Tables
3.1 Material Properties of Steel . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.2 Material Properties of AS4/3501-6 Composite System . . . . . . . . . . . . .
25
3.3 Properties of the ACX QP20N piezoelectric actuator . . . . . . . . . . . . .
26
3.4 Sensor performance capabilities . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.5 Control VI inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
B.1 Beam Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
11
12
Chapter 1
Introduction
In the Fall of 1999, Massachusetts Institute of Technology (MIT) and Microsoft Research
Corp. initiated the iCampus program which is an alliance to \enhance university education
through information technology" [1]. Under the iCampus program the I-Lab project was
started to develop a new framework for science and engineering education [2]. The main
focus of I-Lab is the concept of a web-accessible remote laboratories (WebLabs) that allows
real-time experiments from anywhere at anytime and coupling them with simulation tools.
Several WebLab concepts are being pursued in varied disciplines such as microelectronics
to chemical reactions. This thesis describes the development of the one such concept, the
Mechanical Structures I-Laboratory (MSI-Lab).
The MSI-Lab was created because mechanical structures courses can be greatly benetted from having experimental projects. However, these projects, while relatively simple
to operate, are often time consuming to setup. As a result, only one of the numerous mechanical structures courses oered by the MIT Department of Aeronautics and Astronautics
nominally conducts experiments.
1.1 Motivation
MSI-Lab allows students to have access to laboratory equipment at all times. The student
will have real-time data from the laboratory displayed on the same platform they create and
13
run their analytical simulations. Having both the analytical and physical results from an
experiment side by side will allow for quick feed back and evaluation of the analytical models
developed in the classroom. It will also allow for the student to study where errors in the
physical setup occur.
Once a WebLab is set up, it has several practical advantages over a traditional laboratory. A WebLab can also be leveraged by multiple courses, in multiple departments over
multiple universities. The long-term proposal is to have several universities develop a set to
WebLabs. Thus, instead of each school spending time and eort creating and maintaining
dozen dierent labs, they build one (or a few) elaborate laboratory and share it with a dozen
dierent schools. Additionally, due to the remote nature of the system, more users can access
one piece of laboratory equipment over given amount of time than a traditional laboratory.
For example, consider a class with two hundred students all required to perform the same
laboratory in a given week. A traditional laboratory would require the students to come
in at specied times and either work in very large groups using one piece of equipment, or
in smaller groups with numerous pieces of identical equipment. The former solution does
not allow for more individual access to the laboratory equipment and the later does not efciently use space or money. However, a WebLab can be accessible twenty-four hours a day
seven days a week. Thus student use can be spread over more time requiring less laboratory
setups. This can actually be the enabling feature of an academic laboratory which requires
a large amount of capital to create a single laboratory setup. WebLabs can also operate
near autonomously for long periods of time requiring almost no sta time, but for regular
maintenance. It takes up much less space as no people need direct access to its facilities.
There is no chance of user injury, nor can the laboratory itself be harmed by the user.
A WebLab system also has additional uses including illustrating lectures with experimental exercises. It is also a good introduction to remote operation of scientic equipment
which is a common occurrence in the aerospace eld.
14
1.2 Objectives
The objective of the MSI-Lab project is to design a platform for easy creation of remotely
operated mechanical structures labs. It is created to allow better access to and improved
quality of mechanical structures experiments. To accomplish this task several key goals were
decided upon.
The user experience should be as close as possible to actually being at the laboratory.
The user should have access at any time from any computer with a commonly available
web browser.
The laboratory should be exible enough to allow for dierent levels of mechanical
structures classes to utilize it.
No special manual adjustments should be needed for the normal operation of the
system.
New laboratory realization should be easily deployed within the platform.
The system should be secure from outside tampering.
The WebLab concept was devised to increase the availability of laboratories while reducing the overhead required to implement them. Experiments allow students to see real
responses and test the validity of model developed in lecture. However, much of the time,
the cost and time to set up a laboratory are prohibitive. From a practical point of view,
those created labs that are created typically employ low cost equipment with limited availability. Due to limited space availability, labs often have to be assembled and disassembled
each time they are used to save laboratory space. Most students have tight schedules during
times when most labs are available. Thus they need to rush through a laboratory to get to
another appointment.
No WebLab will completely replace the experience of a complete `hands-on' lab, but a
well designed one can add to the educational experience when no `hands-on' laboratory would
ordinarily be available. The WebLab can also allow for a more comprehensive laboratory
setup than what can be created in the time constraints of a normal lab assembly.
15
1.3 Outline
This thesis describes the design of the platform created during the MSI-Lab project, its
current capabilities as well as currently proposed additions. While there is little published
literature currently available, Chapter 2 provides a basic overview of all the WebLab projects
at MIT at the time of this writing. They are presented in such a way as to demonstrate the
diversity of the labs under development. Additionally, this chapter allows comparison and
contrast between the MSI-Lab and similar projects. In Chapter 3 the basic layout of the
MSI-Lab is discussed. This includes details on the design of the MSI-Lab platform and how
its various components work together to provide a remote academic environment. The MSILab was used by a class in the Fall of 2001 and that experience is documented in Chapter 4,
including student feedback. Finally, Chapter 5 provides an overview of the MSI-Lab project
and discusses the lessons learned during the design and implementation of the MSI-Lab and
suggests improvements.
16
Chapter 2
Current Work in Educational Remote
Laboratories
The MIT I-Lab project is currently seeking to develop a number of WebLabs in various
elds. Each of these WebLabs uses dierent techniques to implement the remote laboratory
concept. However, MIT is not the only institution where remote laboratories are being
developed. Anido et al. [3] provide a survey of some of the work in the eld of electrical
engineering as well as contrasting on-line laboratories and on-line simulations. Many of these
systems were developed for the electrical engineering departments of academic institutions
and utilize Java based applications [4-6]. To the best of the author's knowledge, no work
has been published on a mechanical structures interactive laboratory.
There is a whole range of laboratories being created to study the elds of mechanics,
uid dynamics, thermodynamics, electronics, and chemistry. The earliest of these labs,
the MIT Microelectronics WebLab, has already been used by a number of classes [7]. In
addition to the over half a dozen WebLabs in various states of completion, there is an eort
to build a \universal" architecture and software for generic remote laboratories [8]. This
project, known as the `iCampus Framework' promises to greatly reduce the up front work
of creating a WebLab. Finally, work is also being done on creating an online environment
which encourages collaboration of students using such WebLabs.
17
2.1 MIT Microelectronics WebLab
The MIT Microelectronics WebLab was started by Prof. Jesus del Alamo as an Undergraduate Research Opportunity Project in 1998. The premise of the project is to allow remote
characterization of a microelectronic device. The system allows remote clients to control a
server which carries out real-time measurements on microelectronic devices (usually transistors.) It is presented here as a basis from which to compare the MSI-Lab architecture.
The MIT Microelectronics WebLab basic architecture consists of three main components:
1. Testing hardware (including the object of the experiment)
2. The Server which also controls the instrument
3. One or more remote clients
The main component of the testing hardware is the HP4155B Semiconductor Parameter
Analyzer. This state of the art instrument, combined with the HPE5250A Switching matrix
allows the measurements of current-voltage characteristics of up to eight microelectronic
devices and small circuits. These devices are controlled using the General Purpose Interface
Bus (GPIB) interface, a standard instrument control language.
At the beginning of a session, the client downloads a Java applet from the server. This
applet is then used to create instructions for the server and provides the core of the user
experience. The applet was created to mimic the front panel of the HP4155B. The user
creates a test vector using the applet which is then sent to the server. If the testing hardware
is busy when the test vector is received, the vector is placed in a queue. If the system is
free, the server instructs the HP4155B to perform the programmed experiment. The results
are then sent back to the server and forwarded onto the client's applet. The results are
interpreted by the applet and presented in a graphical format to the remote user. The data
can also be saved for future manipulation.
The primary educational aspects of this WebLab are the creation of the test vector, data
display, and oine data manipulation. Students are thought to learn a great deal from
the creation of a test vector. It forces the students to think about what information they
are after, and how to best obtain that information. When manipulating the display of the
18
results of the experiment, students have to nd optimal ways of displaying data and follow
the standards of the microelectronic world. Oine data manipulation allows the student
better access to the experimental results to compare with models they may have created.
This lab has been used in both at the undergraduate level (in 6.012 \Microelectronic
Devices and Circuits") and the graduate level (in 6.720J/3.43J \Integrated Microelectronic
Devices" and SMA5104 \Fundamentals of Semiconductor Device Physics"). The second
graduate course had twenty students in Singapore using laboratory equipment located at
MIT. Each of these courses used dierent devices at dierent times throughout the year. At
its busiest hour, the lab handled 13 users running 99 dierent jobs, each averaging less than 15
seconds. During the Fall 2001-2002 semester, over 300 students utilized the Microelectronics
WebLab
A `remote' WebLab server was used to allow for educational testing of the latest microelectronic devices. Normally academic experiments of this nature are carried out on mature
systems. However, this server, set up at Compaq's Alpha Development Group, allowed MIT
graduate students access to the latest technology.
2.2 Other I-Lab Projects
There are several projects currently under development in the I-Lab program. This section
will give a basic overview of each of the projects.
A WebLab chemical reaction experiment is being designed by Prof. Jackie Ying and
her students in the Department of Chemical Engineering at MIT. This lab will allow chemical engineering students to monitor the relative chemical composition of a gas over time.
The students will have control over the amount of reactants in the system as well as the
temperature of the reaction chamber. The reaction output will be measured by both a gas
chromatograph and a mass spectrometer. One major advantage of using a Web Lab architecture for this system is the increased safety of the remote operation. The user interface
for this lab has not yet been developed. However, with each full reaction experiment taking
on the order of twelve hours to perform, user scheduling and interface becomes a major issue. Currently this group is looking into recreating recent graduate student research on new
19
methods of cleaning automobile exhaust. This reaction would take on the order of minutes
instead of hours. The group is planning on initial classroom deployment of their lab in Fall
2002
Prof. Clark Colton and his co-workers in the Department of Chemical Engineering at
MIT are designing a WebLab to study uid heat exchange [9]. In this system a pipe with
a hot uid is surrounded by a pipe with cold uid. The students can control the ow rates
of the pipes and the temperature of the hot uid. Sensors then measure the temperature
of both uids at various points along the pipes to allow the students to determine the heat
transfer rates. To access this lab the students are required to download a browser plugin
written in Java 2. Unfortunately, most of the web browsers available to students do not yet
support Java 2. This lab was rst used in the Fall of 2001 by a class of 63 students.
Prof. Kevin Amaratunga and his students are developing the Intrumentalized Flagpole
WebLab [10-14]. This lab is dierent form the others in that the students do not actually
control any aspect of the lab, but instead have access to a large amount of data collected from
an instrumented agpole. The students can read the data from several sensors including
wind measurement devices, thermocouples, accelerometers and strain gauges. The lab is
access through java applets much like the Microelectronics WebLab. However, unlike the
Microelectronics WebLab, much of the lab controlling software was made with the use of
available National Instruments applications. This lab is also coupled with several online
simulations. These applets allow the user to perform numerical analysis of several systems.
This lab forces its students to learn to sift through the large amounts of data an experiment
can generate and determine what is important and how it can be manipulated into useful
information. This lab has been used by several courses in the Department of Civil and
Environmental Engineering at MIT.
Two other WebLab projects are in the early phases of development. One involves the
use of a shake-table to simulate structural response to seismic vibrations. This type of lab
is useful for architectural and civil engineering students. The other lab will study polymer
crystallization using a remotely controlled microscope, heater and camera.
Victor Chang (a graduate student in the Department of Electrical Engineering and Computer Science at MIT) and others have studied and designed ways to allow WebLab users
20
to collaborate while performing their experiments [15, 16]. One drawback to using a remote system to perform academic laboratories is that, instead of working in a lab group,
the students are isolated from each other. This can be solved through online collaboration
tools. Tested using the MIT Microelectronics WebLab, the prototype system developed by
Chang allows users to work as a group and individually simultaneously. The user can send
individual test vectors to the server and monitor the results while at the same time seeing
the group's test vector and results. The system works using a token scheme, where one user
has control and can modify the test vector, but this control can be passed to another user
at any time. While only a small sample of data has been collected on the usefulness of this
scheme, it shows that students allowed to collaborate with each other performed better as
a whole than those that worked individually. This system can also allow an experienced
tutor to join a group. Thus the tutor can monitor the group's progress and provide useful
suggestions and explanations.
Finally, work is being done on Framework headed by the Microsoft Research Corp. This
will be a `universal' architecture and software frame work for building WebLabs and other
remote learning environments. This work is being built upon the Educational Fusion concept
which intends to: \augment on-line learning with a simulation substrate providing collaboration, feedback to student and diagnostic info to sta" [8]. This system plans of oering
services common to most WebLabs. These include user identity checking, lab reservations,
event logging and notication, data storage and user collaboration. Framework will allow
for faster development of remote labs as the lab creators will not have to re-invent each of
those common services.
2.3 MSI-Lab
While the details of the MSI-Lab's architecture will be presented in the next chapter, the
main dierences between it and the other WebLabs should be noted. Unlike all of the
other MIT WebLabs, MSI-Lab does not use a Java based client applet. Instead, Hyper-Text
Markup Language form pushes are used by the client to send commands to the server and
Common Gateway Interface applications are used to stream data back to the user. This
21
simplies the development of the user interface and insures browser compatibility on the
input side while reducing the performance when compared to a java applet. All of the
software and most of the hardware of the MSI-Lab was supplied by a single source, National
Instruments, instead of a conglomeration of various vendors used by the other WebLabs.
This greatly simplied the task of getting the various subsystems to work together. The
experiments performed using the MSI-Lab take about a minute to perform and students are
expected to want to use the system for about a half an hour at a time. Such times require
a well thought out queuing system for lab use. Other WebLabs either have wait times that
are not noticeable, like the Microelectronics WebLab, or so long that usage would probably
have to be previously scheduled, like the chemical reaction WebLab. The MSI-Lab was also
intentionally designed to be a platform which would accommodate a large number of diverse
structural experiments, instead of being designed to accomplish one experiment and then
expanding its capability.
22
Chapter 3
System Layout
The MSI-Lab can be divided into three basic areas: hardware, lab controlling software, and
user interface. While the rst two areas are common to other computer controlled labs, the
user interface is what allows the MSI-Lab to be operated remotely. However, all three areas
were designed such that the goals of the project could be achieved. Figure 3-1 shows the
basic scheme of the system.
Hardware
GPIB
Control
Software
Property
Node
User
User
Interface
Internet
Figure 3-1: System Layout
3.1 Hardware
The MSI-Lab hardware includes sensors, actuators, and testing elastic structure in addition
to the conditioners and ampliers required to convert digital from analog information and
visa-versa. Figure 3-2 shows all of the hardware which is used by the current system and
how it is connected.
23
Actuators
Amplifiers
PCI-6711
D/A Converter
Mechanical Structures
Camera
Server
Sensors
Strain Gauges
SCXI Signal
Conditioner
Accelerometers
Laser Displacement
Figure 3-2: Hardware Layout
24
PCI-6052E
A/D Converter
3.1.1 Mechanical Testing Structures
All of the experiments are conducted on slender structures because they t into the mechanical structures curriculum of the Aeronautics and Astronautics department of MIT. Almost
all of the courses study beams at some point due to their relatively simple nature. Moreover,
they are simple to construct and provide a natural proof of concept for the experiment.
The beams currently used in the MSI-Lab are made from either steel (see Table 3.1) or a
graphite epoxy composite. Composite beams were custom manufactured with both [45=0]3s
and [60=
60=0]2s using AS4/3501-6 composite (see Table 3.2). The rst layup was chosen
to demonstrate a bend-twist coupled composite structure, while the second layup gives a
pseudo-isotropic structure. The composite beams were sized to match the steel beam (457
by 29.6 mm).
Table 3.1: Material Properties of Steel
E 200 GPa
G 80 GPa
8000 kg m
3
Table 3.2: Material Properties of AS4/3501-6 Composite System
EL
ET
EZ
GLT
GLZ
GTZ
LT
LZ
TZ
t
142 GPa
9.81 GPa
9.81 GPa
6.0 GPa
6.0 GPa
6.0 GPa
0.3
0.3
0.3
0.137 mm
1520 kg m
3
The beams can have either a cantilever or a pinned/roller end condition, both of which are
statically determinate. The cantilever end condition has the advantage of a larger amplitude
25
displacement for a given load and beam length.
3.1.2 Actuation Inputs
The MSI-Lab proposes to have two types of actuators, one static and one dynamic. Currently
only the dynamic actuator has been realized. Both actuators are driven by signals created
using the National Instruments PCI-6711 analog output card. This card is capable of sending
one million signals per second to each of its four analog channels. Additionally, it has eight
bits of digital output capability.
Dynamic actuation is performed using ACX QP20N piezoelectric actuators whose properties are shown in Table 3.3. When bonded to a beam and actuated, the piezo induces a
moment which causes the beam to deform. The actuators are placed near the root of the
beams to cause maximum beam tip deection. To achieve maximum actuation, the piezoelectric actuators need a input on the order of 200 V. To achieve this, the analog output
signal is run through a high-voltage amplier. The amplier has a twenty times amplication
and a maximum current of 200 mA.
Table 3.3: Properties of the ACX QP20N piezoelectric actuator
Size (mm)
50.8 x 25.4 x 0.762
Weight (g)
4.82
Capacitance (F)
0.12
Voltage range (V)
200
Maximum extension () 264
Maximum Force (N)
129
The proposed static actuator will consist of an electric motor connected to a linear drive.
This would allow for point loads to be applied to the beams at given locations by means of
prescribed displacements. The motor would be controlled using the digital output from the
PCI-6711. In addition, a load cell would be connected to the system to monitor the load
applied to the beam.
26
3.1.3 Sensor Channels
The state of the beams are monitored by various sensors. This section describes the capabilities of the various sensors. This information is summarized in Table 3.4. The sensors
chosen are able to measure displacement, acceleration and strain. This gives the students
the chance to study the advantages of measuring each attribute.
The signals generated by the sensors are passed through conditioners mounted in a SCXI1000 mainframe. The mainframe multiplexes the signals and passes them on to National
Instruments PCI-6052E analog input card. This card has a maximum rate of 333,000 samples per second. The SCXI system was chosen due to its exible nature. The SCXI-1000
mainframe has four slots for various conditioners which can be changed if the needs of the
lab shift. The current system has strain gauge conditioners in two slots, an accelerometer
conditioner in one slot, and a voltage sensor used to monitor the laser motion sensor in the
nal slot.
Strain gauges are the most common sensor used to monitor structures. They can determine the surface strain of the object which the gauge is attached. Stain gauges are
inexpensive, but have a relatively low signal-to-noise ratio. Strain gauges are mounted along
the length of the beam, as shown in Figure 3-3. A rosette of three gauges are mounted
to the composite beams to allow for twist measurements at the roots. The strain gauges
are connected to the National Instruments SCXI-1520 strain gauge conditioner in a quarter bridge. Using a quarter bridge allows more channels to be used even though it is not
temperature insensitive as the full bridges. The thermal drift corrections must be processed
at the software level. The MSI-Lab has two SCXI-1520s which each have eight channels
giving the system a total of sixteen possible strain input channels. These conditioners can
be recalibrated through software.
Accelerometers are able to capture the motion of a system by measuring the accelerations
it undergoes. The accelerometers are placed where the motion is expected to have the
greatest amplitude, near the tips of the cantilever beams and the middle of the pinned/roller
beams. The MSI-Lab uses Endevco 750 accelerometers which have a range of
80
g's
and a resolution of 100 mV/g. The accelerometer output is accurate to within 5% for
27
Figure 3-3: Strain gauges mounted on steel beam
vibrations of 5-4000 Hz. The accelerometer signals are wired to a National Instruments SCXI1530 accelerometer signal conditioner. This auto-calibrating module has four accelerometer
inputs.
The Keyence LB-1000 laser sensor allows for accurate displacement measurements of a
single point of the structure. The sensor has a range of 80 mm, a resolution of 180 m, and
a maximum sampling rate of 700 Hz. The laser system has an output signal of 5 V which
is read by the National Instruments SCXI-1120 isolation amplier. This module has eight
channels, but due to the expense of the laser sensor itself, only one is used.
Finally the user would also have the ability to view the structure using a video camera.
Currently the camera does not have enough resolution to provide much quantitative data,
however it does allow the user to observe the beam's behavior during the experiments. A
grid is placed behind the beam to give the user a frame of reference for any beam motion.
Still under implementation is the addition of a strobe light to the system to allow the user
to `slow down' the motion of the beam and help in the visualization of the motion. The
frequency of the strobe light would be controlled using the PCI-6711.
3.2 Laboratory Controlling Software
The structure is controlled using a set of Virtual Instrument (VI) applications created in
the G language using National Instruments Lab View version 6i. The structure controlling
28
Table 3.4: Sensor performance capabilities
Sensor
Strain Gauge
Accelerometer
Laser
Camera
Measurement Range
Strain
N/A
Acceleration 80 g
Displacement 40 mm
Image
320x240 pixels
Resolution
10 strain
100 mV/g
180 m
1 pixel/mm
Max Frequency
DAQ limited
4000 Hz
700 Hz
5 Hz
VI program is essentially a while loop that contains ve actions: signal generation, signal
output, sensor input, graphic creation, and optional le generation. The VI has multiple
inputs, shown in Table 3.5. Whether or not the user has control over these various inputs
is determined for each lab and set in the user interface. A block diagram of an example
structure controlling VI can be seen in Figure 3-4
Table 3.5: Control VI inputs
Input
Format
Function
Signal Type
Integer
Changes the output signal: 0-sine, 1-triangle,
2-sawtooth, 3-square, 4-white noise
Frequency
Double Float Frequency of output wave form
Amplitude
Double Float Amplitude of output on scale from 0 to 10
Buer Length Double Float Length (in seconds) of output and input buers
Data Rate
Integer
Number of samples per second of data
(both input and output)
Signal
Boolean
If true, shows signal to piezo on graph
Laser
Boolean
If true, shows laser data on graph
Strain Gauges Integer
Determines which strain gauge's data is shown:
0-none, 1 to 5-corresponding gauge, 6-all
Time scale
Double Float Time scale of plot
File Name
String
Name of output le
File Save
Boolean
If true, creates an output le containing current
input and output buers
Each time the VI is started or the output signal type is changed, the mean value of each
input is determined over a period of two seconds. These mean values are then subtracted
during all other iterations. This method removes the output bias which is generated over
time due to thermal drifts.
Both the output signal and the sensor inputs are buered. Buering ensures that no
29
Inputs
Signal Generator
Signal Type
Frequency
Amplitude
Generates an array of
time/amplitude points.
Sine (et. al) Waveform
Buffer Length
Data Rate
Signal
Laser
Strain Gauges
Output Write
Write output signal to output
DAQ buffer AO Config,
AO Start, AO Write
Time Scale
File Name
File Save
Elastic Structure
Input Read
Plot Setup
Create an array of read in input
from DAQ buffer.1 AI Config, AI
Start, AI Read, Basic Averaged
DC-RMS, Waveform Scale and
Offset
Removes data which
user doesn't want to
visualize. Index Array
Plot Graph
File Save
Creates an output graph
with a time axis length
determined by user input.
Property Node XScale
Saves both input and output
in spread sheet format with
time stamps. Export Waveforms
to Spreadsheet File2
Controling Commands
Waveform Data
1. First buffer read captures the DC values of each channel. Afterward, DC value is subtracted from
signals. Additionally both read and write only use the config and start VIs during first iteration.
2. Slightly modified to automatically overwrite any previous file of same name and not prompt user
Figure 3-4: Block diagram of structure controlling VI (with important subVIs shown in
italics)
30
data is lost. This allows for smooth output signal generation. However, both the output le
and the graphical display can only present what is in the buers. Because of this, the input
data and the output data are out of phase. That is to say, at a given point, the input buer
has what the sensors just read, while the output buer has what is next to be sent to the
actuators.
The structural controlling VI creates a graphical image of both the input and output
signals. The created image is multi-colored with each color corresponding to a specic
actuator or sensor. The time axis scale is controlled by the user, while the data axis is
auto-scaled. Additionally the user can control what data is shown on the plot. The user can
choose to either have each sensor and actuator shown or hidden.
The output data le created by the VI consists of a date and time stamp for each line
of data, followed by both the actuator and the sensors readings at that time. The data is
presented in a spread sheet like format.
3.3 User Interface
All of the user's interactions with the experimental setup are handled using National Instruments G Web Server which makes HyperText markup Language (HTML) and other
documents available on the internet. The user accesses the server from a client computer
using a web browser.
3.3.1 Site Layout
The web site is divided into two areas: the secure and the unsecure. The unsecure side
of the site has various pages describing the layout of the system and its capability. The
secure pages allow the user to control the experiments and access the Matlab scripts (see
Section C.1). The G Web Server has the capability to handel basic site security. To reach a
secure page, the user must supply a proper username and password. The layout of the web
site is shown in Figure 3-5. This gure shows the various levels of the web site. Any user
connected to the internet can access the unsecure `Home Page'. From there they can go to
31
a page oering an overview of the MSI-Lab layout, which in turn links to a number of pages
which give detailed information on the various subsystems. From the Home Page, users with
the proper password can reach the experiment pages. Each experiment being hosted on the
MSI-Lab would have its own page and user/password combinations.
When the user tries to gain access to the experiment, the system checks to see if any
of the structures requested is available (how this is done is described in Section 3.3.3.) If
all of the possible the structures are currently in use, the user enters a queue. The user's
client displays the queue HTML page which simply has the statement: \Your are currently
number X in line." where X is replaced by the number of people waiting in the queue ahead
of the user in question. This page reloads itself every ve seconds to update for changes in
the queue.
When the user is at the front of the queue (or if there is no one using the system) they are
redirected to a page with three frames distributed vertically. This experiment control page
can be seen in Figure 3-6. The topmost frame contains the queue page from before. The
middle frame contains all the controls for the actuator output. In addition, the middle frame
contains links to the various visualization options: animated output data, static output data,
and video feed. The bottom frame contains the le generation control where the user can
create and download sensor data les.
3.3.2 Matlab scripts
Any number of Matlab scripts are available for user download depending on the experiment
being implemented. The Matlab scripts can serve several purposes. First, scripts can be
created for the students to run simulations before or simultaneously with the experiment.
Next, scripts are available to convert the data les created in LabView to Matlab variables.
Finally, scripts can be provided to manipulate the raw data generated by the experimental
run. The instructor for each individual experiment can choose how much of each script they
want the students to create on their own. Examples of the data loading and analysis types
of scripts can be found in Appendix C.
32
Figure 3-5: Layout of web site
33
This is your place in line.
When it gets to 0 you have control
From here you can access the
data from the strain gauges (see below)
Enter the type of signal, the frequency
and the amplitude, then push the Update
button. The beam output will not change
unless the update button is pushed
Clicking DONE will give
control of the beam to
the next person in line
Enter the name of the file you wish to
create. A .dat extension will be
automatically added
Figure 3-6: Control web page
34
3.3.3 CGI Applications
One of the main goals of this project is to allow the MSI-Lab user to control the experiments
remotely. To do this, the user can command the MSI-Lab server over the internet using a
Common Gateway Interface (CGI) program. In order to access the full capabilities of the
lab, the user must have Mathworks' Matlab software and a web browser which has serverpush animations, such as Netscape's Navigator 4.X. The user can use other browsers, such
as Microsoft's Internet Explorer, but some of the animations have reduced frame rates. Thus
the system as it currently stands cannot be considered fully compatible with all available
web browsers. This problem should be alleviated with updates by National Instruments to
their LabView software.
CGI is a standard for external gateway programs to communicate with Hyper Text Transfer Protocol (HTTP) servers. On the World Wide Web (WWW), when a client (in this case
a web browser), sends a request whose Universal Resource Locator (URL) species a CGI
application, the server decodes the request, loads the application, and executes the application. The application generates data and returns it to the server. The server then sends
a reply to the requesting browser that contains the data. All of the CGI applications are
written in the G language. There are three basic CGI applications used in the MSI-Lab: VI
control, queueing and graphical applications.
VI Control Application
The VI controlling CGI applications read in user specied variables as part of the URL sent
to the server by the user's client. The CGI applications then modify the states of the VIs
that control the experiments. The CGI applications also load up a HTML form with generic
markers and modies those markers according to the input variables. These HTML forms
are sent to the server which in turn sends them to the client. This process is illustrated in
Figure 3-7.
An example of a HTML document used to control a VI can be seen in Figure 3-6 (with
comments in grayed areas). Here the user has one menu ring where they can control the
signal type, and two text elds where they can control amplitude and frequency (see Sec35
1. Client request URL that describes
CGI application over the internet
WWW
Client
2.Server loads and executes CGI
application passing along data
HTTP
Server
4. Server returns document which
contains CGI data over Internet
CGI
Application
3. CGI application returns
data to server
Figure 3-7: CGI application control scheme
tion 3.2 for more information on these variables). If the values were as shown in Figure 36, and the user clicked on the `Update' button, the client would send the following URL:
http://ibeam.mit.edu:8000/cgi-bin/rulercgi.vi?signal=1&amplitude=100&frequency=10. Here
`ibeam.mit.edu:8000/cgi-bin/rulercgi.vi' is the WWW address of the rulercgi.vi CGI application, and the rest of the URL contains the controlling variables. When the server receives
this URL from the client, it runs the VI control application (here rulercgi.vi ). This application processes the rest of the URL and updates the virtual instrument controlling the
structure. The CGI application also loads an HTML document similar to the one which the
user currently has. The CGI application changes the shown values of the elds to match
what the user has just inputted. An example block diagram can be seen in Figure 3-8. This
modied HTML is then sent back to the client. If the elds were not changed, the user
would see the values as they were when the page was rst loaded. Examples of the HTML
les used by this CGI application can be seen in Appendix C.
When the user rst accesses this type of CGI, the URL does not include any sort of
controlling variables. In this case the CGI loads up the default values. In addition, the
applications also have minimum and maximum values for each user controllable variable and
will default to those if the user inputs a values outside the allowable range.
36
Read Input
Convert Input
Reads in a CGI request from server.
Outputs all user inputs and other
info for that CGI request. Read
CGI Request
Converts keyed array to array
of string values indexed by
variable name. Keyed Array
Update Page
Convert Input (2)
Replaces markers in control.htm
with actual values of variables.
Replace Substring
Converts string values to proper
numerical values as needed.
Additionally limits values to fall
between predefined amounts. If
no value is given by user, resets
to a default. String to Number, In
Range and Coerce
Write to VI
Updates the all the input variables
of the structure control VI.
Property Node Control Variable
Write Output
Release CGI
Send the server the updated
web page to send to user.
CGI Write Reply
Tells the server the CGI
is finished. CGI Release
Figure 3-8: Block Diagram of typical VI control application (with important subVIs shown
in italics)
37
Queueing Application
The queueing CGI is used to control access to the experiment. Figure 3-9 is a diagram of
an example queue VI. Only one user at a time can control each structure. If a second user
tries to access the experiment when it is currently in use, they (and all subsequent users)
are placed into a queue. The queueing CGI does not explicitly get called on by the user.
Instead, the queue HTML page automatically refreshes itself by calling the queueing CGI.
When the queue CGI is called, it makes a note of the Internet Protocol (IP) address of the
client. This is put into an array of IP addresses. A separate array has the time at which
the queue CGI was accessed by that client. The CGI applications then feed the server the
HTML page with the client's IP address array index to indicate to the user their position
in the queue. At the same time, the arrays are monitored such that if any value in the time
array is more than forty-ve seconds old, that IP address and time are deleted from their
arrays. This elimination time of forty-ve seconds would need to be adjusted depending on
the system constraints. If it is set too short, a slow system could think that a user has left
when they have not. A longer setting means that the experiment is left idle while the system
determines that the old controller has logged out. If no one is in the queue when someone
accesses the experiment, or the person at the front of the queue changes, the queueing CGI
will stop and restart the structure controlling VI. This allows the structure's sensors to be
reset and all thermal biases removed. If no client tries to access the queueing CGI for over
thirty seconds it will stop the structure controlling VI. This means that the experiment is
idle when no one is using it.
Graphical Applications
The graphical CGI applications are special LabView applications which return VI front panel
images instead of documents. There are two graphical CGI applications used by the MSILab, .snap and .monitor. The .snap returns a static image of the specied VI, while .monitor
resends the image at specied intervals causing it to animate.
38
Read Input
Cleanup
Reads in a CGI request from server.
Outputs the IP address of user and
other info for that CGI request.
Read CGI Request, Keyed Array
If no CGI requests come
in for 30 seconds, cleans
data directory of all files
older than five minutes
and stops beam.vi
User Search
Expire?
Checks to see if current IP address is
already in address array. If so, updates
the corresponding slot in the time array,
otherwise address to end of address array
and adds current time to end of time array.
Checks all time array and
deletes any address/time
slot which hasn't been
updated in 15 seconds
Update Page
New Controller?
Updates que.htm to tell user their place in
the queue by replacing $place$ their index
in address array. If user is new controller,
changes <!--link--> to load all control
frames. Also tells the beam.vi to run or
stop (stop if new controller.) Replace
Substring, Property Node Run/Stop
Returns true if address
in front of address array
has changed, or if the
array is empty.
Write Output
Release CGI
Send the server the updated
web page to send to user.
CGI Write Reply
Tells the server the CGI
is finished. CGI Release
Figure 3-9: Block Diagram of queueing application (with important subVIs shown in italics)
39
40
Chapter 4
Platform Test
When the MSI-Lab had been developed to a state where it was thought possible to use in a
class, it was tested in a small graduate class. This test of the MSI-Lab gave insights into its
performance that would not be otherwise possible.
4.1 Background
The Fall 2001 Structural Dynamics class (course number 16.221) of the MIT Aeronautics
and Astronautics department was the rst group of students to use the MSI-Lab. They
were given a copy of the handout found in Appendix B.1, and two weeks to complete the
assignment. The class consisted of six graduate students, and the assignment was given
towards the end of the term. The students were told that the MSI-Lab was in an early
stage of development and that they might have problems using it. They were given contact
information for the MSI-Lab administrator and were told to notify the administrator of any
problems or questions they had with the experiment.
4.2 Student Assignment
The experiment the students were asked to perform was based on the outline found in the
16.221 section of Appendix A.4. The students were given access to a cantilever steel beam
(see Figure 4-1) to perform structural dynamic studies. They were also given the beam
41
properties and asked to perform an analytical analysis of the beam before carrying out their
experiments. The students objectives are to nd the resonance frequencies of the structure
both analytically and experimentally and to discuss the results of both methods.
H
W
L
Figure 4-1: Diagram of Beam Setup
The motivation of such an assignment is that the students would see the limits of the
analytical models they had developed in class. By using a remote laboratory, it was expected
that the students would perform the experiments shortly after performing the analytical
analysis. Perhaps they would have both results on their computer screens at the same time
and be able to make rapid evaluations of the results.
If they had done everything as expected, the students would have found that the analytical results consistently over estimated the natural frequencies of the structure. While there
are numerous possibilities for the discrepancies (as discussed in Appendix B.2) the details
are not important. What is really crucial is that the students begin to think about these
possibilities.
The laboratory assignment also asks the students to explore areas of structural dynamics
that are diÆcult to analytically model, such as nonlinear behavior. It also gives them a bit
of experience in processing experimental data.
42
4.3 Usage and Performance Data
While the students had access to the MSI-Lab, several observations were made of the lab's
usage and performance.
4.3.1 Student Usage
The student usage of the lab was recorded and is presented in Figure 4-2. This graph shows
number of users at a given hour which actually gained control of the beam during the period
of the assignment. The dotted lines are located at the midnight hour of each day. For
example, on Day 0 (the rst day) there were two users during the hour starting at 9:00 PM
Users per hour
4
3
2
1
0
0
Students receive assingment
and one during the 10:00 PM hour.
Th
1
F
2
Sa
3
Su
4
M
5
Tu
6
Assingment due
Users per hour
4
3
2
1
0
6
W
7
Th
8
F
9
Sa
10
Su
11
M
12
Tu
13
Assignment Day
Figure 4-2: Number of users per hour which accessed the beam controls during class assignment
From this graph it can be seen that the lab was used at least once per day, except on
days 2,3 and 9 which fell on weekends. The day before the assignment was due (the eleventh
day) had the most number of users, which peaked to four users at the 4 PM hour.
43
4.4 Laboratory Performance
There were two major problems with the MSI-Lab platform which were identied during this
test. The rst problem was unexpected program errors in National Instruments LabView
which caused the entire platform to stop working. The cause of these errors is still under
investigation. The problem is believed to be associated with the LabView software, and not
the MSI-Lab itself. The technical support sta at National Instruments suggested that the
LabView software might be installed incorrectly. No systematic way was found to predict
when such a system crash would occur. The only solution to the problem was to monitor
the system and restart it when a crash had occurred.
The second problem involved the queuing system. When the system was being used to
collect data, particularly when a data le was being created, there was a system-wide slow
down. The data collection and beam control program were given highest priority to ensure no
data was lost. However, the HTTP server would not process requests as quickly as expected.
This caused the queuing system to register some of the users as having left the system. As
a client is supposed to respond every ve seconds, the original time for the queuing system
to wait for a response from a client was 15 seconds. To correct for this problem, the user
expiration time was extended to 45 seconds. The problem was not noticed and, therefore,
not corrected until the last night of the assignment.
4.5 Student Response
During the period of the assignment, only one student contacted the administrator to help
with the experiment. This student had no experience using Matlab, and needed assistance
using the Matlab scripts. Additionally, several students contacted the administrator to notify
him that the system was not responding. This would occur whenever the system crashed.
The students were asked to ll out a survey after they used the lab. This survey was
designed to obtain feedback from the students and can be found in Appendix B.1. The
survey consisted of two parts. The rst part asked the students to give a quantitative value
from 1 to 5 on how much they agreed with the given statements. A response of 1 would
44
indicate the student strongly disagreed with the statement, while 5 would indicate a strong
agreement. The following are the questions and the mean/standard deviation of the scores.
With only six responses, the statistical signicance of the data is questionable, but can give
some indication on which areas need improvement.
1. The lab handout was clear. 4.3/0.52
2. The background information on the web site was useful. 3.3/1.37
3. The web site was accessible. 3.0/1.67
4. The experiment controls were easy to understand. 3.2/1.47
5. The Matlab scripts were easy to use and well integrated. 4.7/0.52
6. The system was quick and responsive. 2.5/0.55
7. The system was stable and bug-free. 2.3/0.82
8. I would have learned more by being physically at the lab. 3.2/0.98
9. I felt I had a physical understanding of the experiment. 4.0/1.10
10. This was a good use of my time. 3.3/1.37
In addition to the quantitative responses, the students were asked to write down any
additional comments or suggestions. The students provided a large number of comments
which will help in the next iteration of the MSI-Lab design. The comments were broken down
into generalized statments and are listed below (followed by the number of such comments).
Controls confusing/diÆcult to use/cluttered (2)
Camera image not clear/helpful (4)
Unclear on graph time vs. buer length (4)
Data is too noisy (2)
45
4.6 Discussion of the Results and Needed Improvements
Based upon the feedback of the students, the MSI-Lab accomplished its goal of providing the
students with a mechanical structures experiment which they could remotely manipulate.
The students felt that they had as good of an experience as would have had using a more
traditional laboratory setup. Despite not being able to physically see the experiment, they
said that they had a good understanding of what was occurring. These statements were
made despite the MSI-Lab not being fully functional.
The ability of the lab to log usage was extremely helpful. The usage data showed that,
despite being warned that the laboratory was unstable, many students chose to wait until
the last possible night to perform their experiments. The students were also using the system
longer than expected. As there was only six students in the class this was not much of a
problem. However, the student behavior shows that some scheduling scheme must be in
place for a larger class. While this might limit the exibility of having a remote laboratory,
not having a schedule risks a log jam of the laboratory on the last night of any assignment.
Even with a schedule in use, their usage could still be exible by giving students a specic
24-hour period to use the system instead of limiting them further.
The use of the platform by an actual class of students showed that there are several areas
of improvement that need to be implemented in the next design iteration. The primary
corrections to the system are those associated with system stability. The system needs to be
stable independent of the number of users on the system and what tasks they are performing.
An unstable system leeds to student confusion and frustration. Before the MSI-Lab is used
again for a class, more tests should be performed simulating large numbers of users. Even
so, it will be diÆcult to predict all states the system could be put in by users.
A number of students who used the MSI-Lab found the structure control interface to be
confusing. The user interface is an integral part of the MSI-Lab. One student asked for a
better explanation of how to use the controls on the control page, while another complained
that the page was already too cluttered. While they had access to all controls they wanted,
46
they had diÆculty using the controls they had. One exception to this was a student who
had seen the MSI-Lab demonstrated and the controls manipulated by one who understood
them. Thus, one possible solution is to demonstrate the system for each class which would
use it. However, the controls should be arranged in a more intuitive manner so that such
an in-class demonstration is not required. Perhaps a tutorial on the web site might improve
user understanding. There was a page much like Figure 3-6 on the web site, but the students
either did not nd that page, or had diÆculty understanding it. Putting more descriptive
information on the actual control interface would lead to a more cluttered interface. However,
a well developed `help' section and tutorial would solve a number of issues that the students
raised including data buer lengths and data noise.
Another problem the students noted was the poor quality of the image generated by the
camera. While the resolution of the camera image is diÆcult to improve, it is possible to
improve its image by using a dierent camera orientation. During the class assignment, the
camera was placed directly above the beam looking down. If the image is framed such that
the entire length of the beam is shown, even the largest beam displacements are sometimes
diÆcult to discern. However, if the camera is placed close enough such that beam movement
is easily seen, the entire beam, and thus the mode shapes, cannot be discerned. Placing the
camera at the root and slightly above the beam looking along its length would allow the
whole beam to be shown and small deections to be better detected. However, such an arrangement would make it diÆcult to keep the whole beam in focus and to make displacement
measurements.
47
48
Chapter 5
Conclusion
A WebLab that allows users to have access to a mechanical structures experiment via the
World Wide Web has been designed and implemented. This MSI-Lab is a framework which
allows structural experiments to be performed remotely at any time for any computer connected to the internet.
5.1 Overview
The MSI-Lab is a framework which consists of one or more mechanical structures which
can be either statically or dynamically actuated. Various sensors are used to monitor the
structures' behavior. Remote users can manipulate both the actuator signal and sensor
data via the internet. All of the software was implemented using National Instruments
LabView development tools. The control signals are sent to CGI applications using HTTP
form pushes. User access is coordinated using a queuing application and it is continuously
monitored.
This lab was tested in a small graduate student class. While overall reaction to the lab
concept was positive, there was denite feedback which indicated that the system still needed
many improvements.
49
5.2 Successful Results
While the MSI-Lab still requires a number of improvements to fully realize all the goals of
the project, several accomplishments have been made. As it currently stands, the system
is able to remotely actuate a structure, monitor the results, and transmit them to a user.
This ability has been integrated into a web site which provides details of the platform and
its experiments as well as simulations which can be downloaded.
In Chapter 1, a list of project goals was presented. The success of the system in achieving
those goals is discussed next.
The user experience should be as close as possible to actually being at the laboratory. The
system allows users to manipulate all the same inputs available to someone physically in
the laboratory. Users are able to monitor the same data and can observe the behavior of
the structure using the camera. However, the camera image is of low quality, and all of the
inputs and responses are subject to time delays. The students using the lab seemed to agree
that the platform is successful in meeting this goal.
The user should have access at any time from any computer with a commonly available
web browser. With the exception of system down time, this goal has been fully met. The
MSI-Lab can be used by users with Windows, Macintosh and UNIX based operating systems.
The laboratory should be exible enough to allow for dierent levels of mechanical structures classes to utilize it. The MSI-Lab does not currently have a static actuator which
would be required to perform some of the experiments described in Appendix A. Once a
static actuator is included, this goal will be met.
No special manual adjustments should be needed for the normal operation of the system.
The system is currently not stable enough to realize this goal.
New laboratory realization should be easily deployed within the platform. In order to test
this aspect, a new experiment would need to be developed for the system with someone who
did not help in the MSI-Lab development. However, for any new experiment, the sensors
and actuators' interfaces will remain the same. Therefore, no diÆculties are expected in the
deployment of new mechanical structure experiments.
The system should be secure from outside tampering. The experimental section of the
50
web site is password protected, and, thus far, no tampering has been detected.
5.3 Future Work
While the improvements discussed in Section 4.6 are required to enhance the MSI-Lab's abilities to conduct the experiment given to the structural dynamics class, other improvements
can be done to increase the overall capabilities of the system. The implementation of a static
actuator will allow the MSI-Lab to perform simple point load testing. Adding a controllable
strobe light will improve the quality of the images produced by the camera and allow the
camera to be used to take useful measurements.
Work needs to be done to optimize the performance of the queuing routine. One task
would be to add a user timer which would both report how long each user accesses the
controls, and removes the user from the system after spending a certain amount of time.
The latter would prevent one user from controlling an experiment for extremely long periods
of time. Additionally, the best numbers need to be found for how often a user should
notify the system they are present and how long the system should wait for such a response
before removing a user. If the system is notied too often, system resources are wasted. If
the system is not notied often enough, or if the wait time is too short, users legitimately
waiting in the queue will be removed. A longer wait time means the system will sit idle for
longer between users.
Improvements also need to be made in system response times. At this point one computer handles all the structure actuation and measurement as well as serving the web site
and handling request from remote users. This causes the system to become overloaded at
times and it slows down. This is especially noticeable when users take up large amounts of
bandwidth downloading data les. Both the queueing problem and the performance issues
might be eliminated with the implementation of the `Framework' application (Section 2.2)
currently in development.
Once these improvements have been implemented, the system should be tested again.
It is very desirable that the next test be conducted within a larger group of students, so
statistically signicant conclusions can be drawn. This will allow more detailed renements
51
on such aspects as the user interface.
Finally on-line structural simulations will be made available on the web-site. Examples
of such simulations would be a nite element solver with a graphical user interface or a single
degree of freedom mass-spring simulation. These could be used in laboratory assignments so
that the students would not need to develop their own analytical models. Like many of the
features of the MSI-Lab, the incorporation of on-line simulations into an assignment would
be left to the discretion of the course instructor.
52
Bibliography
[1] iCampus Home. 15 Jan. 2002. MIT. 25 Jan. 2002 <http://icampus.mit.edu/>.
[2] MIT > I-Campus > I-lab. MIT. 25 Jan. 2002 <http://i-lab.mit.edu/>.
[3] Anido, L., M. Llamas, and M. J. Fernandez, \Internet-Based Learning by Doing," IEEE
Transactions on Education, Vol. 44, No. 2, May 2001.
[4] Shen, H., Z. Xu, B. Dalager, V. Kristiansen, . Strm, M. S. Shur, T. A. Fjeldly, J.-Q.
Lu, and T. Ytterdal, \Conducting Laboratory Experiments over the Internet," IEEE
Transations on Education, Vol. 42, No. 3, August 1999, pp. 180{185.
[5] Gonzalez-Casta~no, F., L. Anido-Rifon, J. Vales-Alonso, M. Fernandez-Iglesias, M. L.
Nistal, P. Rodriguez-Hernaandez, and J. Pousada-Carballo, \Internet Access to Real
Equipment at Computer Architecture Laboratories Using the Java/COBRA Paradigm,"
Computers and Education, Vol. 36, 2001, pp. 151{170.
[6] Aktan, B., C. A. Bohus, L. A. Crowl, and M. H. Shor, \Distance Learning Applied to
Contorl Engineering Laboratories," IEEE Transactions on Education, Vol. 39, No. 3,
August 1996, pp. 320{326.
[7] del Alamo, J. A., L. Brooks, C. McClean, J. Hardison, G. Mishuris, V. Chang, and
L. Hui, \The MIT Microelectronics WebLab: a Web-Enabled Remote Laboratory for
Microelectron Device Characterization.".
[8] Framework. 24 Jan. 2002. MIT. 25 Jan. 2002. <http://icampus.mit.edu/framework/>.
53
[9] I-Lab / Heat Exchanger Project. 9 Nov. 2001. MIT. 25 Jan. 2002 <http://heatex.mit.edu
/presentation.html>.
[10] Welcome to agpole.mit.edu. MIT. 25 Jan. 2002. <http://agpole.mit.edu/>.
[11] Green, D., Sensor Technologies and Application to a Real Time Monitoring System,
Master's thesis, Massachusetts Institute of Technology, June 2001.
[12] Lingam, S. K., User Interfaces for Multimodal Systems, Master's thesis, Massachusetts
Institute of Technology, June 2001.
[13] Mishra, T., Real-Time Communication and Control of a Sensored Environment, Master's thesis, Massachusetts Institute of Technology, June 2001.
[14] Schlinglo, J., Development of Interactive and Real-Time Educational Software for Me-
chanical Principles, Master's thesis, Massachusetts Institute of Technology, June 2001.
[15] Chang, V. and J. A. del Alamo, \Collaborative WebLab: Enabling Collaboation in an
Online Laboratory.".
[16] Chang, V., Remote Collaboration in WebLab - an Online Laboratory, Master's thesis,
Massachusetts Institute of Technology, June 2001.
54
Appendix A
Example Laboratories
The MSI-Lab is designed to accommodate dierent levels of diÆculty for teaching structural
mechanics, from sophomore level beam theory, to advanced graduate structural dynamic
courses. The following are example laboratory outlines for each structures course currently
oered in the Aeronautics and Astronautics Department of MIT which could benet from the
MSI-Lab. These are here to show the potential of the MSI-Lab system. Actual laboratories
would be designed by the course instructors to fulll their specic educational objectives.
A.1 16.010-16.040 - Unied Engineering
A.1.1 Objective
Experimentally validate the Bernoulli Euler Beam model.
A.1.2 Hardware
Steel beam with cantilever end condition
Steel beam with double pinned end condition
Two Static actuators
Two Laser sensors
55
5 strain gauges (attached to the cantilever beam)
A.1.3 Procedure
1. Using Bernoulli Euler beam theory, determine the displacement of the middle/end
of the pinned/cantilever beam as a function of a point load applied to the quarterlength/middle of the beam. Determine the stress state of the surface of the cantilever
beam.
2. Apply point loads of varying amplitudes to the beams and record sensor readings.
3. Compare results and explain possible errors
A.2 16.20 - Structural Mechanics
A.2.1 Objective
Observe experimentally the response of a system at resonance frequency
A.2.2 Hardware
Steel beam with cantilever end condition
Heavy mass (attached to free tip of beam)
One Laser Sensor
One accelerometer
One Piezo Actuator
A.2.3 Procedure
1. Numerically determine the natural frequency of the system and estimate the increase
in response at that frequency.
56
2. Experimentally determine the natural frequency by oscillating the system around the
estimated frequency.
3. Measure the dierence between the amplitude of the resonance and 80% resonance.
A.3 16.21 - Techniques for Structural Analysis and Design
A.3.1 Objective
Experimentally validate a Finite Element analysis of a beam with dierent boundary condiions
A.3.2 Hardware
Steel beam with cantilever end condition
Steel beam with double pinned end condition
Two Static actuators
Two Laser sensors
A.3.3 Procedure
1. Apply point loads of varying amplitudes to the beams and record sensor readings.
2. Using the nite element method, determine the displacement of the middle/end of
the pinned/cantilever beam as a function of a point load applied to the quarterlength/middle of the beam.
3. Determine number of elements required to converge the analytical analysis to within
1 mm of deection.
57
4. Compare the deection versus load of the experiment with the converged nite element
analysis.
A.4 16.221 - Structural Dynamics
A.4.1 Objective
Experimentally nd the natural frequencies and modes of a cantilever beam and compare
with those found using analytical methods. Additionally, gain some awareness of nonlinear
eects.
A.4.2 Hardware
Steel beam with cantilever end conditions
5 Strain gauges
One Laser sensor
One accelerometer
One Piezo actuator
A.4.3 Procedure
1. Estimate the rst three natural frequencies and modes of the beam using the nite
element method.
2. Find the natural frequencies of the physical beam by sending a broadband signal to
the actuator. Use provided Matlab scripts to perform a FFT on the data from the
sensors.
3. Actuate the beam at the experimentally determined frequencies. Observe its behavior
and try to use the strain gauge data to determine mode shapes.
58
4. Stimulate the rst mode at various amplitude and determine if the response is linear.
5. Explain dierences between model and experimental results
A.5 16.222 - Mechanics of Filamentary Composite Materials
A.5.1 Objective
Experimentally validate the Classical Laminated Plate Theory
A.5.2 Hardware
Composite beam with symmetric layup and cantilever end condition
Composite beam with non-symmetric layup and cantilever end condition
Two Static actuators
Two Laser sensors
12 strain gauges (rosette at root of each beam)
A.5.3 Procedure
1. Apply point loads of varying amplitudes to the beams and record sensor readings.
2. Compare results to those found using Classical Laminated Plate Theory.
A.6 16.241 Advanced Structural Dynamics
A.6.1 Objective
Evaluate various sensors abilities to capture structural dynamics responses
59
A.6.2 Hardware
Steel beam with cantilever end condition
Composite beam with cantilever end condition
10 strain gauges (5 each beam)
Two accelerometers
Two laser sensors
Two piezo actuators
A.6.3 Procedure
1. Apply broad band signal to beams.
2. Obtain data using all available sensors at various sampling rates.
3. Observe the abilities of the various sensors to capture higher order resonances of the
two dierent beams at dierent data rates.
A.7 16.242 - Aeroelasticity
A.7.1 Objective
Experimentally study response of structurally coupled wing to external excitation.
A.7.2 Hardware
Composite beam with non-symmetric layup and cantilever end condition
7 strain gauges (3 gauge rosette at base of beam)
Two laser sensors
One piezo actuator
60
A.7.3 Procedure
1. Analytically determine the response of a structurally coupled wing to sinusoidal fuselage motion.
2. Actuate beam with sinusoidal motion and monitor response.
61
62
Appendix B
Sample Lab Assignment
This appendix is composed of a sample MSI-Lab assignment for a graduate level structural
dynamics course. Both the example assignment and the solution set are presented. Matlab
scripts, which would be supplied with the lab, are included in Appendix C.1.
B.1 Assignment
Mechanical Structures I-Lab
The purpose of this lab is to give you an opportunity to study the structural dynamic
response of a physical system and compare it to an analytical model. Specically you will
look into the natural frequencies and modes of a cantilever beam. Additionally you will
study nonlinear eects of a physical system.
In this case the system is a steel beam clamped at one end as shown in Figure B-1. The
beam's properties are given in Table B.1.
The motion of the beam is controlled via a piezoelectric actuator located near the clamped
end. Several sensors are used to measure the response of the beam. An accelerometer is
attached near the tip of the beam and ve strain gauges are spaced evenly along the length
of the beam. Details of the actuator and the sensors can be found at the lab's web site:
http://ibeam.mit.edu:8000/
63
Table B.1: Beam Properties
40:6 cm
2:94 cm
H
0:122 cm
Esteel
200 GP a
steel
8000 kgm 3
L
W
H
W
L
Figure B-1: Diagram of Beam Setup
Procedure
1. Using nite elements, nd the rst three natural frequencies and mode shapes of the
beam.
2. Find the natural frequencies of the physical beam. This is accomplished by sending
a broadband signal to the actuators. This causes all the modes of the beam to respond. Record the output and use provided Matlab scripts to determine the natural
frequencies.
3. Actuate the beam at the resonate frequencies and observe its behavior. Try to determine the shapes of the modes.
4. Observe the nonlinearities of the overall system by stimulating the rst mode with
increasing amplitudes
64
5. Write up a report. Make sure you show all your work for part 1. Discuss the observations you made of the physical beam. Explain any dierences between the analytical
and experimental results. Include plots the spectral analysis. Determine at what
amplitude the beam behavior becomes nonlinear.
Instructions for web site
Use a computer with both Matlab and Netscape Navigator installed (all Athena terminals
will work.)
Go to the URL: http://ibeam.mit.edu:8000/
Click on the 16.221 link
Enter the user name: 221 and password: *****
The background link contains all sorts of useful information on the experimental setup.
The downloads link contains a list of Matlab les to be used for data analysis. Following
the experiment link enters you into a queue. When you reach the front of the queue you
will be moved to a page that allows you to control the beam. From this page you can modify
the signal being sent to the beam actuator and observe the sensor output.
Visuals: If you would like to observe the data in pseudo real time you can click on the
View Strain Gauge Response and a separate window will be created. This window will
contain an animated plot of the strain gauge data. You can modify what is being seen by
using the Modify Graph section, just make sure to click on the Modify Graph button,
otherwise nothing will change.To observe video of the beam in motion, click on the Video
link.
Output: To change the output, alter the Signal Type, Frequency and/or Amplitude
and click the Update button. The signal will not change until the Update button is pressed
Data les: These can be created by entering a lename and click the Record and Save
button. Use the Matlab script dataload available in the downloads link to load the data
into Matlab.
Important: When you have nished using the beam, make sure you click the Done
button or close the browser.
65
Student Survey
Please take the time to ll out this survey to help us learn how to improve on this lab.
Please rate who much you agree with the following statements on a 1 to 5 scale: 1 stating
that you strongly disagree with the statement, a 5 stating that you strongly agree
1.
The lab handout was clear:
12345
2.
The background information on the web site was useful:
12345
3.
The web site was accessible:
12345
4.
The experiment controls were easy to understand:
12345
5.
The Matlab scripts were easy to use and well integrated:
12345
6.
The system was quick and responsive:
12345
7.
The system was stable and bug-free:
12345
8.
I would have learned more by being physically at the lab: 1 2 3 4 5
9.
I felt I had a physical understanding of the experiment:
10. This was a good use of my time:
12345
12345
How does this lab compare with a more conventional one?
What was the biggest problem with using this lab?
Do you have any specic suggestions for improving the web site interface?
Do you have any specic suggestions for improving the educational experience of the lab?
Should this lab be used again next year? (Yes) (No) (Only if you make the following
changes)
Any additional comments:
66
B.2 Solution
Question 1. Using nite elements, nd the rst three natural frequencies and mode shapes
of the beam.
The Matlab script at the end of this section was used to perform the FEM study of the
beam. Using the given information on the beam, the following beam element matrices were
created:
2
66 12 6l
66 6l 4l2
EI
K = l3 6
64 12 6l
6l
where
m
2l 2
2
156
6
6
6 22l
ml
M = 420 6
6
6
4 54
3
12 6l 7
7
6l 2l2 7
7
7
12 6l 7
5
6l
2l2
is mass per unit length,
l
13l
22l
54
4l 2
13l
13l
156
3l 2
22l
is the element length,
E
3
13l 7
7
3l2 7
7
7
22l 7
5
(B.1)
4l2
is the modulus and
I
is
the moment of inertia. Note that the eects of having the sensors, actuator and associated
wiring is not taken into account. This is based upon the assumption that they will have little
eect on the system (the wires for instance account for less than 10% of the system weight).
The natural frequencies shown below were found using ve elements. A convergence study
found that the third frequency was converged to within one percent using just four elements
and 0.3% using ve. Convergence on the modes is more diÆcult, and a ner renement is
required. Figure B-2 plots the modes shapes created using 20 elements. Also, the modes
were plotted using only the displacement data. If the element shape functions had been used
instead of just the displacements, smoother plots could be created with fewer elements.
!1
= 5:98 Hz
!2
= 37:5 Hz
!3
= 105 Hz
Question 2. Find the natural frequencies of the physical beam. This is accomplished by
sending a broadband signal to the actuators. This causes all the modes of the beam to respond.
Record the output and use provided Matlab scripts to determine the natural frequencies.
Figure B-3 was created using the experimental procedure outlined in the handout. From
this gure, one can see that the experimental data had spectral peaks at:
!1
= 5:3 Hz
!2
= 32 Hz
67
!3
= 60 Hz
!4
= 90 Hz
1
0.8
0.6
0.4
0.2
0
−0.2
−0.4
mode1
mode2
mode3
−0.6
−0.8
0
5
10
15
20
25
30
35
40
45
Figure B-2: First three beam modes found using 20 elements
Note that all these values are about 85% less than those found analytically, except for the
third frequency. The third frequency is not a beam resonance, but a pure electromagnetic
interference coming from powering system (60 Hz is the fundamental frequency from all power
outlets in the U.S.). Thus, the actual frequencies and the analytical results have the same
ratios but dier in scale. The analytical results could be improved by a number of means such
as taking into account the weight of the strain gauge wires and the actuator. Adding mass
to the analytical model would lower all the frequencies it nds. Another potential source
of error is associated with inaccuracies on the beam material properties. Also, it might be
that the root of the beam is not perfectly clamped, changing the boundary condition on
the problem that directly aects its dynamics. All of these issues, manufacturing, boundary
conditions and assumptions can lead to incorrect analytical results.
Question 3. Actuate the beam at the resonance frequencies and observe its behavior. Try
to determine the shapes of the modes.
68
sg1
sg2
sg3
sg4
sg5
output
laser
0.8
0.7
Magnitude FFT
0.6
0.5
0.4
0.3
0.2
0.1
0
10
20
30
40
50
60
70
frequency (Hz)
80
90
100
110
Figure B-3: Spectral analysis of beam response
The following plots were created by actuated the beam at 5.3, 32 and 90 Hz, respectively.
The plots show the output of all ve strain gauges (in microstrain). Each strain gauge
measures the strain on the surface of the beam. From this we can back out the second
derivative of the beam displacement. This can be used to make a basic determination of
the mode shapes. For example, if the strains at a given time of all the gauges were equal,
one could assume that the beam had a constant second derivative. This implies a linearly
increasing rst derivative, which leads to a mode with a simple parabolic shape. However,
it is important to note that the strains are known at only a few, discrete, locations.
In the case of the rst mode (shown in Figure B-4), the strain is largest at the root and
goes to zero at the tip of the beam. As all of the measurements are in phase, the beam
has no changes in its bending direction. The decreasing strain toward the tip of the beam
implies that the curvature of the beam is greatest at the root, and the beam straightens
out toward the tip. This is consistent with the analytical rst mode shape. The second
69
mode, Figure B-5 is similar except that the root most strain is out of phase with the rest
showing that there is a change in the second derivative of the beam, thus it is bent back.
The third mode B-6 shows the rst, fourth and fth strain gauges in phase and the second
and third half a cycle out of phase, thus the second derivative changes signs twice. All of
these observations are consistent with the mode shapes found from the FEM modeling.
Gauge 1
Gauge 2
Gauge 3
Gauge 4
Guage 5
100
micro−strain
50
0
−50
−100
59.22
59.24
59.26
59.28
59.3
59.32
time (seconds)
59.34
59.36
59.38
59.4
Figure B-4: Strain gauge response to 5.3 Hz, 200 V piezo input
Question 4. Observe the nonlinearities of the system by stimulating the rst mode with
increasing excitation amplitudes
The system is actuated at 5.3 Hz at 25 to 200 Volts in 25 Volt increments and the
maximum amplitude of the laser output is recorded and plotted (Figure B-7). From the above
procedure, no determination could be made on where the system really became nonlinear
due to the coarse voltage steps. Therefore, tests were conducted between 10 V and 80 V at
greater resolution. The system was found to have a linear behavior up to approximately 60
V input, or a tip displacement of about 2% of the span. No real conclusions can be made
70
20
Gauge 1
Gauge 2
Gauge 3
Gauge 4
Guage 5
15
10
micro−strain
5
0
−5
−10
−15
−20
11.705
11.71
11.715
11.72
time (seconds)
11.725
11.73
Figure B-5: Strain gauge response to 32 Hz, 200 V piezo input
on what the causes of this nonlinearity with the acquired data. However, at 5.3 Hz and tip
deection amplitude of 2%, the tip moves at speeds up to 0.27 m/s. The apparent mass and
damping of the air surrounding the beam may become important, which may start limiting
its amplitude further. This is all based upon the assumption that actuation remains linear
within the voltage range, which is not the case. However, typically the derivative of the
actuation strain as function of applied voltage increases as the PZT material is driven at
higher electric elds. Therefore, even though the data clearly indicates a nonlinear response
of the beam with respect to applied voltage to the actuator, more data would be needed for
a stronger statement of the source of nonlinearity.
B.2.1 Matlab script used for question 1
clear
%rst input the given beam properties
71
15
Gauge 1
Gauge 2
Gauge 3
Gauge 4
Guage 5
10
micro−strain
5
0
−5
−10
−15
41.714
41.716
41.718
time (seconds)
41.72
41.722
41.724
Figure B-6: Strain gauge response to 90 Hz, 200 V piezo input
E = 200e9;
rho = 8000;
W = 2.94=100;
H = 0.122=100;
L = 40.6=100;
%then determine the rest of the properties needed
area = WH; %cross sectional area
I = WH^3=12; %moment of interia
m = arearho1.05; %mass per unit length
10
%Set number of elements and determine element matrices
N = 20;
%number of elements
l = L=N;
%length per element
K = EI=l^3[
l
l^2
6l
2l^2
l;
l^2;
6l;
4l^2];
12
6
12
6
6
4
6
2
l
12
6
l
12
6
l
l
72
20
Figure B-7: Plots used to determine system nonlinearity
M = ml=420[
156
l
22
54
l
13
l
4l^2
13l
3l^2
22
l;
3l^2;
22l;
4l^2];
54
13
l
13
156
l
22
%Set up the global matrices
KT = zeros(2(N+1));
MT = KT;
30
%place the element matrices into the global
for i = 1:N
B = zeros(4,2(N+1));
B(:,2(i 1)+1:2(i 1)+4) = eye(4);
KT = KT+B*K*B;
MT = MT+B*M*B;
40
end
%Apply cantilever end conditions
B2 = zeros(2(N+1),2N);
B2(3:2(N+1),1:2N) = eye(2N);
KT = B2*KT*B2;
MT = B2*MT*B2;
%nd the eigenvalues of the system
[phi, lam] = eig(MTnKT);
50
%nd the natrual frequencies (in Hz)
73
wn = diag(lam).^.5=2=pi;
%nd the mode shapes and plot normalized
mode1 = zeros(2N+2,1); mode2 = mode1; mode3 = mode1;
mode1(3:2N+2) = phi(:,2N);
mode2(3:2N+2) = phi(:,2N 1);
mode3(3:2N+2) = phi(:,2N 2);
hold o
clf
hold on
plot([0:N].l100,mode1(1:2:2N+1).=mode1(2N+1))
plot([0:N].l100,mode2(1:2:2N+1).=mode2(2N+1),--)
plot([0:N].l100,mode3(1:2:2N+1).=mode3(2N+1),:)
legend(mode1,mode2,mode3)
%xlabel('Position (cm)')
%ylabel('Normalized displacement')
74
60
Appendix C
Source Code
This Appendix includes most of the source code which would be needed to recreate the
MSI-Lab. Generating hardcopies of the VIs created in LabView is not possible due to the
graphical nature of the G language, but diagrams of the VIs used in the MSI-Lab can be
found in Chapter 3.
C.1 Matlab Scripts
The following Matlab scripts are available to the students for download from the web site.
The rst, dataload.m, reads in the data from the generated les and stores them in the
Matlab memory as an array. The second, spectral.m, uses the array generated by dataload.m
and performs a Fourier analysis of the experimental data. It then displays the results in a
graphical format.
C.1.1 dataload.m
% DATALOAD reads in data from LabView generated text le and returns
%
arrays out and in# where out is the output value and sg# are the
%
strain gauge values. The user is prompted for the name of the le.
name = input(What is the file name? ,s);
[z,t,sg1,sg2,sg3,sg4,sg5,out,las1] = textread(name,%18c%f%f%f%f%f%f%f%f,headerlines,1);
75
C.1.2 spectral.m
dt=t(3) t(2); % sampling time interval dt
fmax=(1=(2dt)); % upper frequency bound [Hz] Nyquist
T=max(t); % time sample size [sec]
N=length(t); % length of time vector
x = [sg1,sg2,sg3,sg4,sg5,out,las1];
x mean=mean(x); % mean of signal
x rms=std(x); % standard deviation of signal
X k = abs(t(x)); % computes periodogram of x
AS t = (2=N)X k; % compute amplitude spectrum
k=[0:N 1]; % indices for FT frequency points
f t=k(1=(Ndt)); % correct scaling for frequency vector
f t=f t(1:round(N=2)); % only left half of t is retained
f Hz = f t.=2=pi; % changes frequency from rad to Hz
AS t=AS t(1:round(N=2),:); % only left half of AS is retained
%Power Spectral Density:
PSD t=(2dt=N)X k.^2; % computes one-sided PSD in Hertz
PSD t=PSD t(1:length(f t),:); % set to length of freq vector
rms psd=sqrt(abs(trapz(f t,PSD t))); % compute RMS of PSD
plot(f t,AS t)
xlabel(frequency (Hz))
ylabel(Magnitude FFT)
legend(sg1,sg2,sg3,sg4,sg5,output,laser)
C.2 HTML les
These are the HTML les used by the CGI applications (see Section 3.3.3). These les are
read by the CGI applications, altered, and sent to the user. To create the user interface the
HTML les are placed into a single page through frames. The nal image is that which is
shown in Figure 3-6.
C.2.1 Queue HTML
<html>
<head>
<title>Untitled
Document</title>
http-equiv=\Content-Type" content=\text/html; charset=iso-8859-1">
<!{link{>
</head>
<meta
76
10
20
<body
bgcolor=\#FFFFFF">
are number $place$ in line.
<p>&nbsp; </p>
</body>
</html>
<p>You
</p>
C.2.2 Structure control HTML
<HTML>
<HEAD>
<META
HTTP-EQUIV=\Content-Type" CONTENT=\text/html;
CHARSET=iso-8859-1">
<LINK rel=STYLESHEET href=\../../itk.css" Type=\text/css">
<META NAME=\Author" Content=\Internet Toolkit">
<TITLE>I-Structures Test</TITLE>
<script language=\JavaScript">
<!{
function MM goToURL() f //v3.0
var i, args=MM goToURL.arguments; document.MM returnValue = false;
for (i=0; i<(args.length-1); i+=2) eval(args[i]+\.location=' "+args[i+1]+\' ");g
//{>
</script>
</HEAD>
<BODY>
<p><font
face=\Georgia, Times New Roman, Times, serif" size=\+1">
href=\/ibeamwww/ruler.htm" target=\ blank">Show animated strain gauge data
</a> (will be opened in separate window)</font></p>
<p><font face=\Georgia, Times New Roman, Times, serif" size=\+1">
< a href=\/ibeamwww/ruler2.htm" target=\ blank">Show static strain gauge data
</a> (will be opened in separate window)</font></p>
<p><font face=\Georgia, Times New Roman, Times, serif" size=\+1">
<a href=\http://torrey.camarades.com/userpage.php3?resource=1002684072
&amp;force resolution=640 480" target=\ blank">Video of beam</a></font>
<font face=\Georgia, Times New Roman, Times, serif" size=\+1">
(will be opened in separate window) </font></p>
<hr>
<a
<form
ACTION=\/cgi-bin/ibeamcgi/rulercgi.vi" METHOD=\POST"
77
ENCTYPE=\application/x-www-form-urlencoded">
<p><font
size=\+2">Graph Control:</font> show which Gauges
name=\strain">
<option value=\0">None</option>
<option value=\1">Gauge 1</option>
<option value=\2">Gauge 2</option>
<option value=\3">Gauge 3</option>
<option value=\4">Gauge 4</option>
<option value=\5">Gauge 5</option>
<option value=\6" selected>All</option>
</select>,
<select name=\peizo">
<option value=\0">no</option>
<option value=\1" selected>yes</option>
</select>
Peizo Signal,
<select name=\laser">
<option value=\0">no</option>
<option value=\1" selected>yes</option>
</select>
Laser ?</p>
<p>Time duration:
<input type=\text" name=\deltat" size=\15" value=\$deltat$">
(seconds) scales the x-axis, defaults to 3.
<input type=\submit" name=\Submit2" value=\Modify Graph">
<input type=\hidden" name=\frequency" value=\$freq$">
<input type=\hidden" name=\amplitude" value=\$amp$">
<input type=\hidden" name=\Signal Source" value=\$signal$">
<input type=\hidden" name=\form" value=\/ibeamwww/control.htm">
</p>
</form>
<hr>
<select
<form
ACTION=\/cgi-bin/ibeamcgi/rulercgi.vi" METHOD=\POST"
ENCTYPE=\application/x-www-form-urlencoded">
<H1>Beam
Controls</H1>
<P> Signal Type : <BR>
<select name=\Signal Source">
<option value=\0" selected>Sine Wave</option>
<option value=\2">Square Wave</option>
<option value=\1">Triangle Wave</option>
<option value=\3">Sawtooth Wave</option>
78
<option
</select>
value=\4">White Noise</option>
</p>
<p>frequency
(0.1-200 Hz)
<input type=\text" name=\frequency" size=\15" value=\$freq$">
and amplitude (0-200.0 Volts)
<input type=\text" name=\amplitude" size=\15" value=\$amp$">.
<input type=\submit" name=\Submit" value=\Update">
<input type=\hidden" name=\form" value=\/ibeamwww/control.htm">
<input type=\hidden" name=\deltat" value=\$deltat$">
<input type=\hidden" name=\strain" value=\$strain$">
<input type=\hidden" name=\peizo" value=\$peizo$">
<input type=\hidden" name=\laser" value=\$laser$">
</p>
<p><a href=\/cgi-bin/ibeamcgi/rulercgi.vi?form=/ibeamwww/control.htm&
frequency=5&amplitude=0" onClick=\MM goToURL('parent','/ibeamwww
/done.htm');return document.MM returnValue"><font face=\Arial,
Helvetica, sans-serif"><b><font size=\+3">DONE</font></b></font></a>
- Remember to click here when nished with experiment</p>
</form>
<hr>
<p>&nbsp;</p>
</BODY>
</HTML>
C.2.3 Data le save HTML
<html>
<head>
<title>Untitled
Document</title>
<meta http-equiv=\Content-Type" content=\text/html; charset=iso-8859-1">
<script language=\JavaScript">
<!{
function MM openBrWindow(theURL,winName,features)
//v2.0 window.open(theURL,winName,features);
//{>
</script>
</head>
<body bgcolor=\#FFFFFF">
<form method=\post" action=\/cgi-bin/ibeamcgi/savecgi.vi">
<p><font size=\+1">Create Data File</font></p>
79
<p>Name
of le:
type=\text" name=\name" value=\$name$">
<input type=\submit" name=\Submit" value=\create">
<input
</p>
</form>
<p>After
creating le wait at least 10 seconds then... <a href=\/ibeamwww/studata/
$name$.dat" target=\ blank">Download le</a></p>
</body>
</html>
80