Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
Software System for Controlling Web-Based Laboratory
Final Year Thesis
Written By: Timothy Davies Supervisor: A/Prof James Trevelyan
Due Date: 04/11/2002
Abstract
In the aim to provide a more efficient learning environment for students, the
ability for reliable control of laboratory equipment over the Internet has been
achieved. This project is part of the Telelabs initiative and involved the
development of a LabVIEW-coded hardware controller for the Mechanical
Engineering Department’s Position Control Rig.
Several major objectives were involved to achieve this aim. Last year, the
hardware received modification to allow for computer control (Lin 2001), so this
year, the project consisted of writing the software to control the hardware locally
and via the Internet. Some of the complications of streaming live video over the
Internet in a LabVIEW/Telelabs environment were also addressed, with some
success. Finally, the system was tested using students enrolled in the third
year “Control and Mechatronics 322” unit. The students were then asked to
participate in an online survey about the system and their responses were
analysed.
Testing yielded many positive results about the reliability of the software. Over
half the students enrolled in the unit participated in the survey and many
interesting suggestions were received that could improve the learning
environment the system provides. At this time, there are still more students that
prefer performing their laboratory experiments in the classroom. This proportion
should decrease considerably however, when the suggestions they made have
been addressed. Most students also indicated that they thought they would
learn more from the remote experiment than from a simulation alone.
For the laboratory to be completely remote next year, there are several issues
that require attention. The most important of these is the results collected by
students, must be more consistent. Hardware fatigue is the cause, so the rig
should be overhauled early next year. If the other suggestions from students
are also completed, the laboratory should be a great success for students next
year.
Timothy Davies
85 Stafford Way
Wanneroo 6065
Western Australia
30 October 2002
The Dean
Department of Engineering
University of Western Australia
Nedlands 6009
Western Australia
Dear Sir,
It is with great pleasure to submit my thesis entitled:
Software System for Controlling Web-Based Laboratory
This thesis was undertaken with the Department of Mechanical and Materials
Engineering, as part of the requirement for my Bachelor of Engineering degree.
It was taken under the supervision of Associate Professor James Trevelyan.
Yours sincerely,
Timothy Davies
Contents iv
Contents
Abstract ........................................................................................................... ii
Contents ......................................................................................................... iv
Figures and Tables........................................................................................ vii
Acknowledgements .......................................................................................viii
List of Acronyms............................................................................................. ix
Chapter 1 ...........................................................................................................1
Introduction......................................................................................................1
1.1 Objectives .........................................................................................2
1.2 Scope of this Thesis..........................................................................3
1.3 Experimental Setup...........................................................................5 1.3.1 Hardware Components used by the Position Control Rig .................................. 5
Chapter 2 ...........................................................................................................6
Background and Related Work........................................................................6
2.1 The Need for Web-based Laboratories .............................................6
2.2 “Information Technology Online” .......................................................7
2.3 “A Collaborative WebLab” .................................................................8
2.4 A “Telerobotic Training System”........................................................9
2.5 A “Framework for Internet Telerobotics”..........................................10
2.6 Analysis of Other Universities .........................................................11
2.7 Telelabs ..........................................................................................11
Chapter 3 .........................................................................................................13
The Simulations.............................................................................................13
3.1 Using Dynamic Equations of Motion ...............................................14 3.1.1 The Mathematical Model................................................................................... 14
3.2 Using Control Theory ......................................................................17 3.2.1 The Simulation’s Objectives.............................................................................. 18 3.2.2 Simulation Design ............................................................................................. 18 3.2.3 Simulation Testing............................................................................................. 19
Chapter 4 .........................................................................................................20
Local Control .................................................................................................20
4.1 Overview of Local Control ...............................................................20
4.2 The Hardware Master .....................................................................21
Contents v 4.2.1 The PID Controller ............................................................................................ 21
4.3 Interface Design..............................................................................22
4.4 FieldPoint® .....................................................................................23 4.4.1 FieldPoint® Components .................................................................................. 23 4.4.2 FieldPoint® Operation....................................................................................... 24 4.4.3 Real-time Data Collection and Control.............................................................. 24 4.4.4 Using Watchdog Timers.................................................................................... 25
Chapter 5 .........................................................................................................26
Remote Control .............................................................................................26
5.1 The Remote Client ..........................................................................27
5.2 DataSocket .....................................................................................27 5.2.1 DataSocket Fundamentals................................................................................ 27 5.2.2 The DataSocket API.......................................................................................... 27 5.2.3 The DataSocket Server..................................................................................... 28
5.3 The Bandwidth Problem..................................................................28
5.4 Packet Loss and Packet Surging ....................................................29
5.5 Communications in the Telelabs .....................................................29
Chapter 6 .........................................................................................................31
Real-Time Video Transmission .....................................................................31
6.1 Problems associated with Video Transmission ...............................31
6.2 Choosing a Camera ........................................................................31
6.3 User Datagram Protocol..................................................................32
6.4 Design of Camera Software ............................................................32
6.5 Camera Testing...............................................................................33
Chapter 7 .........................................................................................................34
Feedback from Students ...............................................................................34
7.1 Analysis of Results..........................................................................35
Conclusions...................................................................................................44
Recommendations for Future Work...............................................................46
References ....................................................................................................49
Appendix I...........................................................................................................I
The Hardware Master as a Service ..................................................................I
Appendix II...................................................................................................... XII
Rig Configuration on the LOL-Server ........................................................... XII
Appendix III.................................................................................................... XIII
Components of the Position Control Rig ..................................................... XIII
Contents vi
Appendix IV ....................................................................................................XV
Communication Protocols ............................................................................XV
Appendix V ...................................................................................................XVII
Calculating the Response Function............................................................XVII
Figures and Tables vii
Figures and Tables
Figure 1: The Position Control Rig.................................................................................................5 Figure 2: Flow of data with the Information Technology Online system. (Stoll & Hopp 2002) .....7 Figure 3: The architectural setup. (Marin & Sanz 2002) ................................................................9 Figure 4: Framework used by The Telerobot...............................................................................10 Figure 5: The Telelabs System Architecture................................................................................12 Figure 6: Components used in the mathematical model. ............................................................14 Figure 7: The finite state machine used to model friction. ...........................................................17 Figure 8: The Simulation Interface...............................................................................................18 Figure 9: Manual and computer controlled operation of the Position Control Rig. (LIn 2001)....21 Figure 10: Configuration tab of the Hardware Master..................................................................22 Figure 11: The FieldPoint® Modules.. .........................................................................................24 Figure 12: Illustration showing the rate of signal change.............................................................25 Figure 13: The Remote client interface........................................................................................26 Figure 14: The transfer of data between the publisher and the subscriber. .................................28 Figure 15: Representation of a potentiometer. ...........................................................................XIII Figure 16: Differencing circuit used by the Position Control Rig.................................................XIII Figure 17: The PID circuit used by the Position Control Rig...................................................... XIV Figure 18: The servo-amplifier used by the Position Control Rig. ............................................. XIV Figure 19: Representation of a gearbox. ................................................................................... XIV
Table 1: Symbols used for the mathematical derivation of the simulation model. .......................14 Table 2: Parameters used to model the motor. ............................................................................16 Table 3: The time the students spent on the equipment in the laboratory for task1. ...................38 Table 4 Reasons why students performed the experiment for the time they did. ........................38 Table 5: Reasons why students preferred local control. ..............................................................39 Table 6: Reasons why students preferred remote control. ..........................................................39 Table 7: Reasons why students would prefer real hardware. ......................................................40 Table 8: Reasons why students felt comfortable controlling the rig remotely. .............................40 Table 9: Reasons why students felt uncomfortable using the rig remotely..................................41 Table 10: What did you like about using the rig remotely? ..........................................................41 Table 11: What did you like about using the rig locally? ..............................................................41 Table 12: What did you dislike about using the rig remotely?......................................................42 Table 13: What did you dislike about using the rig locally?..........................................................42 Table 14: Can you think of anything we could do to improve the laboratory? .............................42 Table 15: Do you have any other comments?..............................................................................42
Acknowledgements viii
Acknowledgements
There have been many people that have assisted me throughout this project’s
duration all of whom require thanks.
I would especially like to thank my parents for their never-ending love and
support. Without them, it would not have been possible for me to be here at this
stage of my life.
A/Prof. J. Trevelyan has been an excellent supervisor for the whole year and I
would particularly like to thank him for the times when he provided assistance at
times where I have not been able to diagnose server faults.
Dr Wenge Liu also requires thanks, as he allowed suitable access through the
Mechanical Engineering Department’s computer network firewall for me. This
made it possible for a large amount of development and testing to be done from
my computer at home. Without this access, this project would have been
considerably more difficult and time consuming.
Last of all, I would like to thank Mr. Yan Baranski and Dr. Alex Le Dain, for
providing technical support for my project.
List of Acronyms ix
List of Acronyms
TCP – Transmission Control Protocol
IP – Internet Protocol
PID – Proportional, Integral and Differential
UDP – User Datagram Protocol
ISO – International Standards Organisation
OSI – Open Systems Interconnect
I/O – Input/Output
URL – Uniform Resource Locator
ADSL – Asynchronous Digital Subscriber Line
ISDN – integrated Services Digital Network
DSTP – DataSocket Transfer Protocol
HTTP – Hypertext Transfer Protocol
API – Application Programming Interface
LOL – Laboratories-on-Line
MOM – Message Oriented Middleware
ACK - Acknowledgement
PPP – Point to Point Protocol
ISP – Internet Service Provider
IPv4 – Internet Protocol version 4
IPv6 – Internet Protocol version 6
OLE – Object Linking and Embedding
OPC – OLE Process Control
LAN – Local Area Network
WAN – Wide Area Network
CORBA – Common Object Request Broker Architecture
MATLAB – Mathematics Laboratory
DSP – Digital Signal Processor
A/D – Analogue to Digital
D/A – Digital to Analogue
ASCII – American Standard Code for Information Interchange
UWA – The University of Western Australia
List of Acronyms x
DVD – Digital Video Disk
kb/s – Kilobits per second
Mb/s – Megabits per second
OS – Operating System
VI – Virtual Instrument
CD – Compact Disk
MSI – Microsoft® Installer
CCChhhaaapppttteeerrr 111
Introduction
With the ever-advancing use of technology in industry, machinery is being
designed with an ever-increasing proportion of electronics with computer
control. Distributed control and monitoring systems in industry have been
developed that use computers to monitor machine operation and to send control
signals from remote locations when required. Many of these systems operate
using a private Local Area Network (LAN) or Wide Area Network (WAN).
As the popularity of the Internet has increased considerably in the last decade,
connectivity throughout the globe has reached a level where many people can
work from home instead of from the office. It also has provided the facility for
people to monitor and control machinery from anywhere in the world.
This technology can also benefit students, as it can allow them to perform
laboratory experiments on equipment from any computer connected to the
Internet. From this, the Telelabs initiative has evolved.
Telelabs is an online-laboratory management system, developed at The
University of Western Australia (UWA), aimed at allowing students to perform
laboratory experiments from home, in their own time. It manages queues of
students waiting to use the different experiments controlled by the system. An
interface is also provided for academics and laboratory supervisors to mange
laboratories performed on each of the experiment rigs.
Objectives 2
With the traditional laboratory system, it is often not possible for all students to
control the equipment due to time and resource constraints. With a web-based
system, all students are able to control the hardware from home, so they can
spend all the time they need to understand the concepts. This allows students
to become more aware of what they are learning and will be more likely to gain
a lasting knowledge of the experiment topic. The resources required can be
considerably reduced, as the students do not have to be at university when they
perform their experiment.
It is possible to have many different hardware devices managed by this system.
These, for example, could be devices that analyse convection currents in
horizontal pipes, devices that use PID control and devices that analyse
vibration. Integrating control of an experiment rig into the Telelabs system is
the major aspect of this project so remote control can be provided for the
students. The experiment rig chosen for this project was the Position Control
Rig, used for the third year “Control and Mechatronics 322” (CM322) unit.
1.1 Objectives
The major aim for this project was to facilitate an effective Telelabs system
using the Position Control Rig. There were six major objectives for this aim: an
accurate simulation; a stable hardware controller; effective remote interfaces; a
tele-vision system; system reliability testing, and to obtain student feedback.
The simulation involved developing a mathematical model of the system and
implementing that model using the LabVIEW software development
environment. There were several possible approaches and two of these were
analysed for suitability.
The hardware master is the program executed on the runtime computer to
provide control over the hardware to the Telelabs server. This was written with
LabVIEW to use the existing hardware architecture implemented by Lin (2001).
A template was provided, written by Trevelyan (2002) that contained the
necessary software for communication with the Telelabs system. This was
used as the starting point for this part of the development.
Scope of this Thesis 3
The remote client is the interface the students are presented when they perform
their laboratory experiments. This provides access to the hardware master via
the Telelabs ‘Labs-On-Line’ (LOL) server. The development of the remote
client also started from a software template written by Trevelyan (2002).
Effective streaming of real-time video data is a difficult task. The viability of
providing ‘live video’ to students while they are performing their experiments
has been tested with an AXIS2100 network camera, which was purchased this
year. All the software required for this application was written from scratch and
is still under development.
The Telelabs system was tested constantly throughout the project to determine
any areas of unreliability. When items of concern were found, appropriate
action was taken to rectify the problem.
Gathering students’ response to using the system over the Internet was the last
objective. These were analysed so further development of the Telelabs project
can head in a suitable direction.
1.2 Scope of this Thesis
The structure of this thesis follows the order in which the objectives were
developed.
Chapter 2 presents a literature review, which discusses the need for web-based
laboratories and compares the development approaches from other universities
with that used by The University of Western Australia. The first university, The
University of Massachusetts, uses Java client/servlet technology. The second
university, The Technical University of Clausthal, uses a Java/MATLAB
environment. The third university is Jaume-I University, which uses ‘Java3D’
and Common Object Request Broker Architecture (CORBA). The fourth is The
University of Western Australia’s Telerobot. These approaches are compared
and leads to a description of the approach used for the Telelabs system.
Scope of this Thesis 4
Simulation development of the operation of the hardware was the first objective
for this project. Two approaches are discussed in Chapter 3, which were the
use of motion theory, using dynamic equations of motion and control theory,
using transfer functions and Laplace transforms. The design and
implementation is described for both of these approaches.
Chapter 4 describes how the rig is controlled by a local computer. This includes
a discussion about the collection of real-time data and the use of FieldBus
technology in the Telelabs environment. The design of the interface for the
hardware master and the design of the PID controller are also discussed. The
software design specifics of the hardware master template are not mentioned,
as this is proposed for documentation by Trevelyan (2003).
To provide a remote connection to the hardware, knowledge about
communications protocols was required. Ethernet, TCP and IP are only generic
protocols, so they are included in Appendix IV. DataSocket however, is
described in Chapter 5 as it is a major component in the design for remote
control. The transfer of information between the remote client and the hardware
master, and problems such as limited bandwidth and packet loss are discussed.
The ergonomics of the remote interface is important for the students to be able
to perform the laboratory effectively and is discussed in Chapter 5. The
software design specifics of the remote client template are not mentioned, as
this is also proposed for documentation by Trevelyan (2003).
Chapter 6 discusses the design and implementation of the real-time video
transmission system. It includes a description of the problems that were faced
and the approaches to the design that were taken to minimise these problems.
It also describes the theory about why the Universal Datagram Protocol (UDP)
was chosen. The conclusions about the implementation of the live-video
system are then discussed with recommendations for how it could be improved.
Obtaining feedback from students was an important aspect for determining how
effective this online laboratory system is. This was achieved by supervising
laboratories with students working locally on the runtime computer and remotely
Experimental Setup 5
from other computers in the department or from their homes. An online survey
was written and the results are analysed in Chapter 7, but should be analysed
further by someone with more experience with student behaviour
1.3 Experimental Setup
The Control and Mechatronics 322 unit has used the Position Control Rig for
many years. In 2001, the original circuit board (Chew 1997) was modified to
allow for computer control and a basic software system was written for web-
based control. (Lin 2001) This section describes the hardware components
used by the rig.
1.3.1 Hardware Components used by the Position Control Rig
The hardware used for this experiment, shown in Figure 1, consists of the basic
requirements of a feedback, position control system. These components
include:
Figure 1: The Position Control Rig.
• Potentiometers – The set point and feedback potentiometers for
determining desired position and current position.
• Power Supply – To convert 240V AC to 12V DC.
• Gearbox – To increase the velocity of the pointer.
• Servo-Amplifier – To provide control over the amount and polarity of
voltage to the motor.
• Controller – A Proportional, Integral, Differential type controller.
• Servomotor – To provide the motion of the pointer.
• Computer – To read, manipulate and transmit the data.
CCChhhaaapppttteeerrr 222
2.1
Background and Related Work
Technology is integrating rapidly into academia and has led to the development
of new teaching techniques called ‘tele-learning’ and ‘tele-laboratories’. This
chapter discusses the tele-laboratory approaches that are being developed by
other universities. These approaches have been compared with that used by
UWA with the Telerobot and leads to a description of the new approach
currently being developed.
The Need for Web-based Laboratories
The ‘traditional’ laboratory, currently used in the Faculty of Engineering, forms a
significant part in the assessment of students. Usually they are two to three
hours each and supervised by post-graduate students. The number of students
is kept to a minimum wherever possible, but timetabling and cost restraints
usually keep this number between five and ten students for each laboratory
session. The cost of a laboratory includes materials consumed in the exercise,
hire of the facility, hire of the supervisor, and the provision of written material for
the students.
A virtual laboratory only requires a computer with an internet connection and
can allow for an almost unlimited number of students to participate in the
laboratory exercise simultaneously. This means that all expenses related to
“Information Technology Online” 7
physical equipment are avoided, but unfortunately, many ‘quirks’ involved with
real equipment in the real world are difficult to address.
A compromise between these two extremes exists that can reduce the
resources required for laboratory exercises considerably. This is different from
a virtual environment in that the equipment is real, but the students can perform
the experiment from a different location. This use of computers as human to
laboratory interfaces can reduce the impact of many of the disadvantages with
the traditional system. (Boden 2000) For this reason, many universities are
currently developing web-based laboratories.
2.2 “Information Technology Online”
“Information Technology Online”, is an approach to tele-learning in the field of
control systems technology. Stoll and Hopp wrote this case study, in 2002, at
The Technical University of Clausthal in Germany. The way they are
developing this system is slightly different to many other studies that were read,
as it uses Java and the MATLAB/Simulink environment with a DSP card.
Figure 2: Flow of data with the Information Technology Online system. (Stoll & Hopp 2002)
The operation of the system is shown in Figure 2. On the user side, a Java
applet is running as a TCP client within a web browser. The applet opens a
socket connection to a TCP server implemented inside MATLAB. In this applet,
the user can enter the control parameters. The data is transmitted via the
socket to the MATLAB server. After the results have been examined for
validity, they are sent directly to a real-time system containing a Digital Signal
Processor (DSP).
“A Collaborative WebLab” 8
The DSP is connected to the rig by Analogue to Digital (A/D) and Digital to
Analogue (D/A) channels. The values measured from the rig are transmitted to
the DSP and then transmitted via MATLAB, to the applet. The data is
transferred as American Standard Code for Information Interchange (ASCII)
vectors and are sent at approximately two second intervals. If an interruption
occurs while the socket is open, the connection loss triggers an automatic
shutdown of the system to return the hardware to a safe state.
They have reported that there has been positive feedback about the technical
aspects of the project, but they did not specify what these aspects were.
2.3 “A Collaborative WebLab”
The “Collaborative WebLab for Online Microelectronics Device Categorisation”,
recently developed at The University of Massachusetts (MIT) uses Java
client/servlet technology. (Chang and del Alamo 2002) The system, originally
designed for a single user was too restrictive, so they integrated a “modification
token” scheme to allow concurrent connections.
On the client applet, an option has been provided to establish a persistent
socket connection between the applet and the collaboration server. To do this
effectively, they designed a new communications protocol consisting of thirteen
commands for obtaining the users’ status, for token delegation and for
pushing/pulling data to/from the server. The user can obtain the token by
default, by handover or by inheritance. Inheritance operates at random when
the holder disconnects from the collaboration server. An assumption they have
made is that no user will ‘hog’ the token and they have proposed a voting
mechanism to “impeach the hog”.
The user connects to two domains: the group domain and the individual
domain. The holder of the modification token can modify frames in the group
domain. The individual domain remains under the control of the local user
where he/she can perform tests without affecting the group domain.
They have reported success from student testing; however, they did not specify
the areas where the success occurred.
A “Telerobotic Training System” 9
2.4 A “Telerobotic Training System”
The “Telerobotic Training System through the Web”, is an approach being
developed by Marin and Sanz (2002) at Jaume-I University in Spain. It has
been designed to use a virtual 3D Java environment as well as a real robot.
The system architecture design is shown in Figure 3. The client side consists of
a single process implemented in Java and running through a web browser. It
uses the CORBA and HTTP standards to communicate with the server
machine, which consists of several concurrent processes. The communication
between the server and the clients is channelled through the HTTP port of the
computer to avoid firewalling problems.
Figure 3: The architectural setup. (Marin & Sanz 2002)
The server uses three modules. The first is called the “Robot Server” that
accepts the CORBA request to move the robot to a given real world coordinate
position. The second is the “Grasping Server”, which is responsible for the
grasping points for every object present in the scene. The third is the “Camera
Server”, which provides an HTTP interface using a WebCam32 camera.
The main project innovation is that the control program responds to commands
such as ”Pick up the big pen”, which uses an object recognition module that
A “Framework for Internet Telerobotics” 10
operates through CORBA. Details of how they developed this part of the
system were not discussed in this article.
There was no mention of results from student testing.
2.5 A “Framework for Internet Telerobotics”
“A Distributed Framework for Internet Telerobotics”, describes the approach
used by Dalton (2000) for developing the framework for “Australia’s Telerobot”
at UWA. This review is from chapter three of his Ph. D. thesis, which made
considerable contributions to the structure adopted for the Telelabs project.
The framework developed occurred after significant testing on a Common
Gateway Interface (CGI) system developed by Dalton and Taylor (1997) and is
illustrated in Figure 4.
Figure 4: Framework used by The Telerobot.
It uses a hub-based architecture that consists of a Message Oriented
Middleware (MOM) server that allows any number of clients to connect to it.
This architecture was chosen to minimise the number of connections in the
system, while still adhering to Java security rules. The framework provided a
Analysis of Other Universities 11
good basis for developing distributed telerobotic applications, which can easily
be used for mechatronic applications.
Dalton found in the development of the system, that there were many problems
with the use of Java. He found that developing a reliable Java applet was
significantly harder than developing a Java application. Part of this was the
requirement that applets were to adhere to internet security restrictions,
whereas the applications did not. The security restrictions were found to be the
most problematic during the development of the project.
He also found that the ‘virtual machines’ that were incorporated into common
web browsers, proved to become unstable when operated for long periods of
time and often caused the browser or the entire operating system to stop
responding.
2.6
2.7
Analysis of Other Universities
Many of the case studies that were analysed have chosen a Java type
configuration, some with similar ideas used by Dalton because of the cross-
platform and internet capabilities. It has been found now with the Telerobot that
complex Java applications and applets do not perform in terms of long-term
reliability. For this reason, the high-level programming language ‘G’, which
uses the LabVIEW software development environment, has been chosen for its
robust base for cross-platform support instead of Java for the Telelabs project.
Telelabs
“Towards Cost Effective On-Line Laboratories” (Trevelyan 2001) describes the
approach UWA is using for the development of tele-laboratories using the
experience gained with the Telerobot. The system architecture implemented by
the Telelabs project is illustrated in Figure 5.
Telelabs is a means to provide staff and students with remote access to
laboratory equipment in a cost-effective manner using the Internet. The server
and backbone of the software has been designed by UWA and the code was
built by Icon Technologies to provide a rugged, maintainable framework. This
Telelabs 12
system has been designed to allow students to build software modules to add
specific laboratory experiments to the system.
Figure 5: The Telelabs System Architecture.
Students need to be able to collaborate in many laboratory classes. When one
student moves the controls, all the other students in the group can see the
controls on their own panels move at the same time and the name of the
student moving the controls is displayed to the others. This arrangement also
allows staff and students to use the system at the same time so staff can
provide remote assistance. A chat window allows text communication between
all simultaneous users. A separate chat window allows communication
between students waiting in the queue.
A robust system must allow for connection failures, particularly as students use
older computers and may not be able to afford high-quality internet connections.
This system can restore broken connections without interrupting experiments.
In these circumstances, the system waits until the student re-connects and the
results are sent by e-mail even if the student does not. If the queuing time is
long, students can disconnect and rejoin the queue closer to the time when they
are likely to gain access.
CCChhhaaapppttteeerrr 333
The Simulations
Simulations are useful in many fields of engineering. These range from flight
simulators for pilots to computer games for children. Many industries also use
simulations to model an operation, such as a machine, or how many machines
or processes interact with each other. A change of parameters on the
simulation can show outcomes without affecting the real world application,
which is useful for learning new concepts and beneficial when making
decisions, as possible performance benefits or losses can be previously
determined.
The simulation used with the Position Control Rig allows students to practise
before they control the equipment. This provides them with an opportunity to
gain a good understanding of how to use the controls and understand the
underlying principles. When they use the rig, they should have greater
confidence due to a better understanding of its operation and should achieve
better results. This hypothesis should be confirmed with later studies.
Two versions of the simulation were created using two different models to
represent the system. The first uses dynamic equations of motion and the
second uses a transfer function with a Laplace transform. Both simulations
were designed to look as close as possible to the remote client interface.
Additional controls were added in both cases however, to allow additional
understanding and greater variability to the simulation’s application.
Using Dynamic Equations of Motion 14
3.1 Using Dynamic Equations of Motion
The first model for the simulation used motion theory, as this was the approach
used for the simulation written for the torsional vibration rig (Trevelyan 2002). A
mathematical model was formed and then coded in the LabVIEW software
development environment. This model was never completed, as it was
superseded with the second model.
3.1.1 The Mathematical Model
This section describes the approach to developing a mathematical relationship
that could be used to represent the system. The symbols used for the
development are shown in Table 1 and the components included iare illustrated
in Figure 6.
Figure 6: Components used in the mathematical model.
Table 1: Symbols used for the mathematical derivation of the simulation model.
mτ - Motor Torque frictionτ - Torque due to Friction
mk - Motor Torque Constant pτ - Torque on the Pointer
mi - Motor Current pθ - Angular Acceleration of the Pointer
ek - Motor BackEMF Constant tI - Total System Inertia
mθ - Angular Motor Velocity mI - Inertia of the Motor
1n - Number of Teeth on Gear 1 mθ - Angular Position of the Motor
2n - Number of Teeth on Gear 2
Using Dynamic Equations of Motion 15
The total torque generated by the motor can be modelled with two components.
These are the motor torque and the retarding torque caused by back
Electromotive Force (EMF). The motor torque and back EMF constants were
found in the motor data sheet, so were modelled in this way. The formula is
shown in equation(1.1).
m m m ek i k mτ θ= − (1.1)
The output torque of the motor can be used to calculate the torque at the
pointer by including parameters to represent the gear friction and the gear ratio.
This is shown by equation(1.2).
2
1p m m e m friction
nk i kn
τ θ τ = − − (1.2)
Another equation that can be used to calculate the torque at the pointer uses
the total moment of inertia of the system and the angular acceleration of the
pointer. This is shown by equation(1.3).
p t pIτ θ= (1.3)
Combining equations (1.2) and (1.3) forms a second degree differential
equation that can be used to model input current to output position. This is
shown by equation(1.4).
2
1m m e m friction
pt
nk i kn
I
θ τθ
− − ∴ = (1.4)
If we let u pθ= , we can separate the second-degree differential equation into
two single degree differential equations that can easily be solved by a
computer. These equations are shown by equation(1.5) and equation(1.6).
2
1m m e friction
pt
nk i k unu
I
τ − − = (1.5)
p uθ = (1.6)
Using Dynamic Equations of Motion 16
The following constants shown in Table 2 were found from the Portescap
22N28 motor specifications sheet:
Table 2: Parameters used to model the motor.
Motor Torque Constant 19.3mNm/A
Terminal Resistance 5.80ohms
Back EMF Constant 2.02V/1000rpm
Gear Ratio 160:1
Rotor inertia 3.00kgm^2x10^-7
The equations used to model friction were taken from a handout (Trevelyan
2002), showing the simulation derivation of the torsional vibration rig and can be
modelled as a finite state machine with three states. The software module was
part of the supplied code and its operation is described in this section.
Static State: Torque available = 0
Velocity of motor = 0
Applied torque = 2
1m m
n k in
If ( ) 10%mtorqueapplied f θ> + start to move in either positive or negative
direction.
Positive Rotation:
Torque available = applied torque - ( )mf θ
(2
1m m e m m
n k i k fn )θ θ− − (1.7)
The velocity of the motor is calculated by integration. If velocity < go to
static state. Velocity = 0 and Torque = 0 if enacted immediately (t=0).
limv
Using Control Theory 17
Negative rotation:
Torque available = applied torque + ( )mf θ
(2
1m m e m m
n k i k fn )θ θ− + (1.8)
If velocity > go to static state. Velocity = 0, Torque = 0 if enacted
immediately (t=0).
limv−
Figure 7: The finite state machine used to model friction.
The friction function uses several components. These are friction due to:
eccentricity of gear one, which is 2
1
sin 2 nn
π θ
∝ , eccentricity of gear two, which
is
)(sin 2πθ∝ , surface errors, which are ( )R θ∝ and tooth period which
is ( 2sin 2 n )π θ∝ . Friction due to eccentricity of the gears follows a cyclic pattern
due to the changing of radius of the gears at the contact point. As both gears
have eccentricity, the relationship between the eccentricities is also important.
This is modelled by analysing the tooth period. The surface irregularities are
modelled using a random number generator. These sum together to obtain a
cumulative friction function shown by equation(1.9).
( ) ( ) ( ) (22
1
sin 2 sin 2 sin 2n )f R nn
θ θ πθ π θ π
= + + +
θ
3.2
(1.9)
Using Control Theory
The second simulation was written to model the system using control theory.
This gave students the opportunity to experiment with control systems with
Using Control Theory 18
different transfer functions and the opportunity to see the effects of different
step sizes on different numerical integration techniques.
Figure 8: The Simulation Interface.
It was built using the LabVIEW simulation toolbox, which is part of the add-ons
package that came with the UWA license.
3.2.1 The Simulation’s Objectives
Having already studied Control and Mechatronics 322 (CM322), the important
aspects of the course were already known. This then meant determining how
all of these aspects could be incorporated into the Position Control Rig
simulation.
Analysis of a control system (at the third year level) can be performed in the
Laplace, frequency and time domains. To provide analysis in these realms, a
response plot, Bode plot, Nyquist plot and root locus plot were developed.
3.2.2 Simulation Design
The simulation was first written as a standalone application, but when its
performance was at a suitable level, it was incorporated into the remote
interface. The design of the interface is shown in Figure 8.
Using Control Theory 19
3.2.3 Simulation Testing
Considerable testing remains, as there are many unresolved issues. These
have been documented for students that will continue with this project. The
testing method used was to compare the results with those calculated last year
when studying CM322. Testing was done on the time response chart against
the response of the rig itself. It was found that similar parameters gave similar
looking responses in most cases, but had very different amplitudes of
oscillation. A suggested reason for this discrepancy is the way LabVIEW
calculates integrals. This is the major issue with this simulation and requires
resolution.
CCChhhaaapppttteeerrr 444
4.1
Local Control
There are two types of local control available with the Position Control Rig. The
first is the analogue control that uses the set point potentiometer, which was
included with the original design of the rig. (Chew 1997) The second is digital
control using the hardware master on the runtime machine. This chapter will
only deal with the use of the hardware master.
To provide control over the Internet, the rig was modified (Lin 2001) to provide
access to the set point, feedback and velocity signals and to provide control to a
relay and to the motor. This enables the runtime machine access to these
voltages via the FieldPoint® modules. This chapter deals with how the signals
were retrieved from the rig, how they were processed by the computer and how
they were sent back to the rig.
Overview of Local Control
Analogue control does not provide the flexibility to students to be able to modify
the PID parameters, as they must be set with a screwdriver on the circuit board.
Figure 9 shows the changes made to the control loop to allow for computer
control and PID parameter modification.
With the rig physically able to be controlled by a computer, suitable software
could be developed.
The Hardware Master 21
4.2 The Hardware Master
The hardware master is the control software used that provides local, digital
control and access from the Internet. At the commencement of this project, the
Torsional Vibration Rig control software (Trevelyan 2002) was undergoing
testing. This software provided a framework that was adapted for the Position
Control Rig as it used good design rules that aimed at reliability and long-term
maintainability.
Figure 9: Manual and computer controlled operation of the Position Control Rig. (LIn 2001)
4.2.1 The PID Controller
Although the hardware master template formed a strong base for the control
software, many modifications were required to adapt it for use with the Position
Control Rig. One of the major additions was the PID controller. A major
teaching objective of the Position Control Rig is for students to learn about the
characteristics of PID control, so it was important to develop a module that
modelled the pointer response correctly.
Interface Design 22
Three previously written PID controller modules could have been used. The
first one was included with the LabVIEW PID add-on package, but this used
automatic tuning parameters so it was rejected because this experiment was to
use the normal PID gain parameters. Lin (2001) wrote another, but this was
rejected also, as it required considerable modifications to be incorporated into
the new system. The other was written by Harjono (2001) and was accurate
(Zhou 2002), but was also rejected because it was written with poor
programming techniques. It was used however, as a model for the new
controller developed during this project’s duration.
Modern programming techniques emphasise the use of abstraction and
encapsulation (Object Oriented Programming 224 Unit), so these were used to
code a new PID controller.
Figure 10: Configuration tab of the Hardware Master.
4.3 Interface Design
The design of control panels on computers forms part of the Human Computer
Interaction (HCI) field of study. It is important to understand how human
characteristics impact the way an interface should be designed. This includes
the size of the text and information, and the perception and discrimination of
colours. It is also important to understand human cognitive performance
capabilities, for instance, knowing how humans make decisions and how they
process information. (Redman & Rajan 1997)
FieldPoint® 23
Figure 10 shows the most complex looking tab used by the hardware master.
For this to seem as simple as possible, all the different sections were grouped
together so their purpose could be distinguished more easily. The colours used
were to allow for easy distinguishing of the groups, to be aesthetically pleasing
and to have an attempt at a soothing effect on the subconscious. These effects
however, have not been tested. The other tabs used by the hardware master
also follow these design rules.
The controls in the left-hand pane were originally designed using dials. These
were changed to the digital controls however, due to requests from the students
that performed the laboratory, as they could not obtain the required level of
accuracy when collecting their results.
4.4 FieldPoint®
FieldPoint® is an easy-to-use modular hardware platform developed by
National Instruments for distributed Input/Output (I/O) that allows
communication between the control software and the hardware. The generic
term for these devices is ‘FieldBus’ and they are becoming increasingly popular
in industry as an alternative to Programmable Logic Controllers (PLC) due to
their ability to be remotely located and their compact size. They use a high-
level language called “G” as their control language instead of ladder logic or
assembly language, and can be programmed with the LabVIEW software
development environment, which is another major advantage.
4.4.1 FieldPoint® Components
Each FieldPoint® bank consists of a network module, terminal bases and I/O
modules. FieldPoint® also includes a variety of both analogue and digital I/O
modules that can be selected. The ones used for the Position Control Rig are
the AI-100, which is an 8-channel 12-bit analogue input module; the DI-301,
which is a 16-channel discrete input module; the DO-401, which is a 16-channel
discrete output module and the AO-210, which is an 8-channel analogue-
voltage output module.
The Ethernet module currently used in the Telelabs is an FP1600. It can
connect directly to standard Ethernet and Fast Ethernet networks using TCP/IP
FieldPoint® 24
and automatically negotiates with the network for communication at 10Mb/s or
100Mb/s baud.
Figure 11: The FieldPoint® Modules..
4.4.2 FieldPoint® Operation
When an Ethernet module receives a signal from the network, it is transferred
via the bus to the appropriate module. The signal is conditioned and then
transmitted to the hardware. The type of conditioning on the signal depends on
the module involved. It may be filtered and, with the use of specialised
electronics, produce the signal specified by the FieldPoint® configuration file to
be transmitted to the hardware.
An input signal works in a similar manner. The input module receives the raw
electrical signal from the hardware where it is conditioned and passed along the
bus to the Ethernet module and then transmitted to the network card of the
runtime machine. The Object Linking and Embedding (OLE) Process Control
(OPC) server, which is embedded in “FPLVMgr.dll”, then passes the data to the
control software.
FieldPoint® Explorer is a configuration utility provided as an add-on to
LabVIEW. It is used to configure entire banks of FieldPoint® modules including
the range of input values, safety shutdown states, and timeout parameters.
4.4.3 Real-time Data Collection and Control
The latency of each component and transport medium add together to form an
overall delay time. This means the data collected by the computer is not
actually real-time data. However, as it can be determined what happened in
real-time, the data is “deterministic”.
FieldPoint® 25
For the deterministic data to be the best representation of the real-time data, the
sampling speed is an important factor. There are three issues to consider when
dealing with FieldPoint® sampling speed. These are the channel update rate,
data throughput rate and the rate of signal change. The slower of these is the
limiting factor. The channel update rate is how fast the data can be read from
the channels. The National Instruments website and their catalogue provide
these figures. The data throughput rate is how fast the data can travel through
the network module to the computer. The rate of signal change, also known as
a transient is represented by Figure 12.
On state A
Off state t
Transient
Figure 12: Illustration showing the rate of signal change.
It is possible that the I/O module will sample data faster than it can be read.
This is called over-sampling and sometimes the I/O module will read the data
faster than it can be refreshed. This is called under-sampling. FieldPoint® has
no built-in features to prevent the loss of data due to overwriting the prior from
update.
4.4.4 Using Watchdog Timers
A watchdog timer is a safety feature built into the FieldPoint® modules.
Watchdogs are used when control data during transmission is interrupted for a
preset minimum amount of time. The Position Control Rig requires a null-
reference voltage for the motor input of 5V. At this voltage, the pointer velocity
is zero. If transmission of the motor control signal were interrupted, the last
signal would still be sent to the motor. This could make the pointer revolve at
full velocity in either direction, which would require the interruption to be
removed, or the hardware to be reset. Watchdogs have been configured in the
FieldPoint® configuration file to set the null-reference voltage for the motor
signal to stop the motor and 0V for the digital signal to return the rig to analogue
control.
C a t r 5 CChhhaappptteeerr 55
Remote Control
Understanding how the rig was to be remotely controlled required a
considerable amount of research. A lot of this was not directly required by the
scope of this thesis, but was required to gain a better understanding of how the
rig was able to communicate the way it did. This additional understanding was
very useful when diagnosing problems and understanding the properties of the
different communication protocols that were used.
Figure 13: The Remote client interface.
The remote client interface was required to communicate with the LOL server
using the MOM server technique. This was shown to work most effectively by
Dalton (2000) and was redesigned to use DataSocket and TCP/IP. How this
The Remote Client 27
design is affected by problems such as limited bandwidth, transmission lags
and packet loss are also discussed in this chapter.
5.1
5.2
The Remote Client
The remote client is the interface students use to control the hardware over the
Internet. The most important objective was to provide an easy to use interface
for visualising the data and to send control signals. The interface that was
designed, shown in Figure 13, uses the same colour scheme as the hardware
master and allows the user to change the colour of the traces to their own visual
preference. The chart can also be paused, so students can use the zoom
function to calculate required parameters.
DataSocket
DataSocket is an internet programming technology developed by National
Instruments that simplifies data exchange between computers and applications.
It enables programmers to efficiently pass raw data to multiple users over the
Internet without the complexity of low-level TCP programming.
5.2.1 DataSocket Fundamentals
To transfer ‘live’ data with TCP/IP, code must be written to convert the data into
an unstructured stream of bytes in the broadcasting application, as well as the
code to parse the stream of bytes back into its original form in subscribing
applications. DataSocket however, transfers data in a self-describing format
that can represent data in an unlimited number of formats, including strings,
scalars, Booleans, and waveforms. The DataSocket read and write operations
transparently convert the data to and from the underlying byte streams,
eliminating the need to write complicated parsing code. (National Instruments
2001) With DataSocket, the resource name is in the form of a URL. For
example: dstp://130.95.52.245/position.token. The “dstp” (DataSocket Transfer
Protocol) tells a subscribing application to open a DataSocket connection to a
machine with that IP address (the LOL server) and read a file named
“position.token”.
5.2.2 The DataSocket API
DataSocket consists of two components – the DataSocket Application
Programming Interface (API) and the DataSocket Server. The DataSocket API
The Bandwidth Problem 28
is a protocol-independent, language-independent, and OS-independent API
designed to simplify binary data publishing. It consists of four basic actions:
open, read, write, and close. The user’s measurement data is automatically
converted into the stream of bytes that is sent across the network. The
subscribing DataSocket application automatically converts the stream of bytes
back into its original form. (National Instruments 2001)
5.2.3 The DataSocket Server
DataSocket Server simplifies internet communication by managing the TCP/IP
programming. The DataSocket Server is a stand-alone component with which
programs using the DataSocket API can broadcast live measurement data at
high rates across the Internet to several remote clients concurrently.
Broadcasting data with the DataSocket Server requires three components – a
publisher, the DataSocket Server, and a subscriber.
Figure 14: The transfer of data between the publisher and the subscriber.
A publishing application uses the DataSocket API to write data to the server. A
subscribing application uses the DataSocket API to read data from the server.
Both the publishing and the subscribing applications are “clients” of the
DataSocket Server. (National Instruments 2001)
5.3 The Bandwidth Problem
Unfortunately, most students do not have 100Mb/s internet connections and
usually use up to 56kb/s modems or ADSL. With all these different connection
speeds, the throughput of data ranges considerably. In any case, it is desirable
to transmit the minimum amount of data, which contains the maximum amount
of relevant information. This involves the use of a compression technique. It is
possible to “enable software compression” in the dial-up settings in the
Windows operating system, but not in the Mac or Linux operating systems.
Fortunately, it is enabled by default, as many users are not aware of this
feature.
Packet Loss and Packet Surging 29
In addition to this, a mechanism has been designed (Trevelyan 2002) to
compress the data to be transmitted. This module was used as part of the
supplied code.
5.4
5.5
Packet Loss and Packet Surging
TCP/IP packets are numbered at transmission time and reordered when they
reach their destination. This is required as IP can route packets differently,
which means that the packets can arrive in a different order than they were
transmitted. If, after a timeout period an acknowledgement (ACK) packet has
not been received from the receiver, the packet is resent. The packets that
have been received cannot be assembled until that retransmitted packet is
received. This shows the phenomenon of packet surging. There is very little
we can do to minimise these two problems because they are mostly caused by
noise by poor quality components on external networks cannot be minimised by
this project. Packet loss can also occur when a packet collision occurs. When
this occurs, the machine that sent the data waits a random amount of time
before resending the packet and keeps trying until an ACK packet has been
received. This can be a major problem on congested networks and will soon
become a more noticeable problem on the Mechanical Engineering LAN.
Communications in the Telelabs
When a student logs into the LOL server, they are presented with the tasks they
are required to perform. They choose a task and join the queue for that
experiment. When they have been notified that they or a group member has
reached the front of the queue, a remote client is spawned on their computer.
When the student modifies the controls, the control data is transmitted using
TCP/IP to the LOL server, where the hardware master to send the control signal
to is determined and then transmits it there using TCP/IP. The hardware
master converts the data to an appropriate voltage, which is sent through the
appropriate channel on the FieldPoint® modules to the hardware. Sensors on
the rig then update the hardware master using different channels, where it is
determined if there has been a change in state. The data-log, which contains
the new state, the change in positions and the control data, is sent to the LOL
server for storage.
Communications in the Telelabs 30
The state data needs to be updated in the remote clients, so it is transmitted
using DataSocket to the DataSocket server. The control data also needs
updating and is transferred from the LOL server to the DataSocket server,
where both state and control data are transmitted to the remote clients.
While the experiment is operating, the hardware master receives images
pushed from the network camera over TCP/IP where the individual images are
queued and transmitted to the remote clients over UDP/IP at calculated
intervals.
When the students have completed the task and quit the experiment, they are
given an option to email the data-log accumulated by the LOL server. If they
choose to send the data, it is transmitted through the DataSocket server to the
remote user’s configured email account.
CCChhhaaapppttteeerrr 666
6.1
6.2
Real-Time Video Transmission
The transmission of ‘live’ video data has received much funding for its
development largely due to the internet pornography industry but has had
limited success. (Personal communication, Trevelyan 2001) This technology is
also beneficial for remotely monitoring the motion of hardware. A suitable
method for quality video over slow internet connections however, has still not
been developed. An attempt to minimise some of the associated problems has
been undertaken in this project, but only with limited success.
Problems associated with Video Transmission
There are several major problems with real-time video transmission. The
largest is the bandwidth problem and is easily explained with an example. The
bit-rate of Digital Video Disk (DVD) technology is 10Mb/s and when this is
compared with an “average students’” internet throughput rate of up to 10kb/s, it
can be seen that achieving high quality video data over the Internet is currently
impossible. Attempts to maximise the amount of ‘important’ data to be
transmitted and to maximise throughput were addressed in the design of the
camera software and are still being developed.
Choosing a Camera
A comparison between the use of a web-camera with different software
packages and the use of network cameras was undertaken. (Davies and Chan
2002) This showed there were many benefits for the use of a network camera
that outweighed the considerable purchase cost. The advantages included:
User Datagram Protocol 32
configurable bandwidth usage, configurable resolution of images, easy
installation, remote administration, configurable triggering of transmission, they
were standalone devices that can be placed anywhere on a LAN and used
Active-X controls, which could be used by LabVIEW.
6.3
6.4
User Datagram Protocol
The User Datagram Protocol (UDP) provides the ability to send information to
other programs with a minimum of ‘handling’. It contains a minimum of header
information (eight bytes), but does not guarantee the receipt of reliable data
streams. (Postel 1980)
UDP is a connectionless protocol with higher performance; this is because it is
not required to establish a connection with a destination before the data is sent
or received. Instead, the destination for each datagram is configured at the
server and the client listens on an appropriate port. An additional benefit is that
operating systems do not report transmission errors. (National Instruments
2000)
It should be noted that many firewalls and routers at ISPs are configured to
disallow the forwarding of UDP packets. (Dalton 2000)
Design of Camera Software
The designs of the camera software involved an analysis of the problems and
then develop strategies to minimise them. Most of the design however, was to
exploit as many of the network camera’s advantages as possible.
UDP was chosen, as it did not require a checksum calculation so it did not have
to resend incorrect data. Retransmission was deemed unnecessary because
several incorrect pixels or a dropped frame is not detrimental. It also has the
benefit of a larger throughput and faster transmission speeds due to a minimum
of packet handling during transmission.
LabVIEW queues were used to pass the buffered, ordered sequence of JPEG
frames from the camera output to the (proposed) sorting subVI without the
elements being removed. This method was chosen so multiple streams of
Camera Testing 33
different frame rates could be configured and appropriate ones could be
transmitted to users with differing connection speeds.
VIs were created separately from the hardware master and remote client, as it
was easier to work on the modules separately. When they were complete and
had been tested, they could be incorporated into them with minimal debugging.
6.5 Camera Testing
There are many configurable parameters built into the camera software. These
can be found at http://130.95.52.185. Most of these however, only affect the
transmission to the camera master. The most important parameter that was
configurable at this address was the image size. Obviously, we required the
smallest possible image size that still had enough definition to understand the
image. It was found that 3kB images were a suitable compromise.
Most of the testing was done on the remote camera client over a 10Mb/s
internet link, which provided a very smooth image stream. When testing was
performed on a modem link connected at 26kb/s, the stream was of very poor
quality. Transmission was made at 10frames/second and it was initially hoped
that packet loss and UDP would work together to form a suitable stream that
changed automatically for different connection speeds. This however was not
the case and the received data was found to be pointless.
The next step in the development of the camera software is to change the
transmission protocol to DataSocket and to retest the performance.
CCChhhaaapppttteeerrr 777
Feedback from Students
Obtaining feedback from the students was the most significant contribution to
Telelabs that this project provided. This was the opportunity to check that
Telelabs is heading in the correct direction and outcomes from this survey will
effect the direction of future development. It was not required for critical
analysis of the students’ responses in this project, as someone with more
knowledge about human behaviour will arrive at the conclusions with
psychological evidence. This is because the author does not have the training
to provide this; however, a subjective analysis has been made to get a general
idea of the students’ opinions.
The feedback was obtained using students enrolled in CM322 to perform a local
and a remote task and then to complete a survey. The first task, called ‘task1’,
was the laboratory performed the ‘traditional’ way. This involved the students
performing a two hour laboratory task and to complete a formal report to be
handed in as a ‘hard copy’. The second task, called ‘task2’, was considerably
shorter, as it was an extra task for the students and was not worth any marks
for the unit. This task involved logging into the Telelabs system and using the
remote client for the Position Control Rig. A fifteen minute exercise was asked
of them to see how they responded to the way the remote client operated.
The survey was created using an HTML form and aimed at obtaining answers
to several major questions that could influence the direction of Telelabs. These
Analysis of Results 35
were not asked directly, as some students often complete questionnaires by
answering with comments they think are expected and not with what they really
mean. It was then possible to cross-reference their responses to different
questions to determine the answers to the major questions, which were:
1. Do students prefer to control the equipment locally or remotely?
This is an important question and needed to be carefully worded to obtain
accurate results. As the students performed two different tasks, it was
difficult to obtain unbiased answers.
2. Would they learn the same amount if they only used a simulation?
Only their opinions could be tested here, but it allowed us to determine
whether the extra complications of controlling hardware was required.
3. Do students require image data to visualise what is happening?
This question asks if we need to supply a live video feed to students and
deal with the inherent problems associated with it. This question affects the
direction taken for providing the imagery needed by students to understand
the concepts provided by the laboratory exercise.
7.1 Analysis of Results
Analysis was performed on sixty-seven submitted surveys. The actual
questions asked are described in this section, with comments about the results.
1. Your Details: • Student Number:
• Age:
• Gender:
• Ethnic Background:
When designing this survey, it was decided that more students would complete
it if they were under the impression that it might be accessed. This was easily
achieved by asking for their student number. It may have been better to ask the
students to perform the task anonymously, but it was decided that not many
students would have participated in the survey if this were the case.
Analysis of Results 36
The other three parts were included, as it was noted when task1 was being
supervised, that these factors influenced the way the students behaved. The
‘ethnic background’ question received many complaints, which was expected,
and approximately ten percent of students refused to answer it correctly.
2. Task 2 Results: • Enter the rise time:
• Enter the percentage overshoot:
• Enter the settling time:
• Enter the subsidence ratio:
These questions were added so the students would have something to achieve
when they logged in and would learn something about PID control systems.
This also provided the opportunity to determine who had actually completed the
task and who was just doing the survey only and guessing the answers.
3. Did you have any difficulties obtaining the results? This was a multipurpose question, as people that actually did task2 and were
filling in the survey accurately should have answered yes. This was because
the proportional gain parameter that they were asked to use, gave an unstable
waveform from which it was impossible to obtain the results. Thirty-seven
students said they had problems, but only sixteen of them said they had
problems with the proportional gain. It cannot be said that only sixteen students
completed the survey correctly however, because it was mentioned in the
procedure that if this parameter was a problem, they should reduce it until they
could obtain the results. But, they were asked to supply the value that they
used.
The next major complaint was the variance of the results, which obtained seven
votes. This is because the hardware does not provide consistent results. This
major area needs urgent attention.
The next complaint was that the results could only be estimated, this could have
been due to the variance of the results, or that students could not use or were
unaware of the zoom feature. There was one suggestion, which was to add a
coordinate readout from the position of the mouse pointer. This seems like a
good suggestion.
Analysis of Results 37
The last problem was two people could not log in. They did not say why, but a
person emailed the author several times about setting up the system from his
own computer. It seemed like he had problems with a corrupt download so he
was directed to the distribution CDs that were supplied.
Thirty students replied ‘no’ to this question and the general comment was that
the task was easy.
4. If you had never seen the rig before, do you think you would understand what the graph traces represented?
Fifteen students replied yes to this question and the general comment was that
they thought it was an easy concept to understand.
Twenty students answered that they were unsure. This was probably due to
them having the knowledge already, but only one response confirmed this. Two
people suggested that a picture should be supplied. Another two suggested
that an animation or a short video should be provided. One person mentioned
that the graph should have its axes labelled. One student suggested that a
good explanation would suffice.
There were thirty-one ‘no’ responses, eleven of which said they would require a
picture, one student mentioned the axes labels and only three said they would
need to perform the task while physically watching the rig.
5. Do you think a camera image of the rig in motion is important? This question was aimed at asking the students for their opinion about how
much visualisation they required to understand the concepts. The popular
response to this question was ‘yes’ with forty-six votes, meaning that some sort
of visual aids are required.
Fifteen responses suggested that they wanted to see what was happening, two
said they needed it for better visualisation and two students said they thought
that without a camera, the task was just like a simulation. Six students said
they were unsure and suggested that they thought an animation or a video
Analysis of Results 38
would be sufficient. There were fourteen ‘no’ responses, two of which
suggested that they thought the bandwidth requirements were not justified and
five suggested that pictures or an explanation would suffice.
6. How much time did you spend actually operating the controls on the rig in the laboratory for task 1?
When the students were supervised in the laboratory for task1, it was noted that
many people stood at the back at just watched. This question was aimed at
determining why these students behaved this way.
Table 3: The time the students spent on the equipment in the laboratory for task1.
Option Number of Responses
• I just watched 28
• Less than 10 minutes 8
• Between 10 and 20 minutes 14
• Between 20 and 30 minutes 5
• Between 30 minutes and 1 hour 6
• Greater than 1 hour 5
This question provided some sample answers that the students could select so
they would get an understanding of the sort of responses that were required.
These are shown in Table 4.
Table 4 Reasons why students performed the experiment for the time they did.
Option Number of Responses
I did not know what I was required to do 10
Other people were operating 40
I did not feel confident controlling the rig with other people
watching
6
I could not be bothered, other people were getting the results
for me
3
I felt there was not enough time for everyone to have a turn 16
I came back and used the rig in my own time 11
This was all the time I needed to get the results 15
Additional responses added by the students were the “Know it alls hogged the
controls”; they used the rig in their own time to ‘play’ with it, and the most
Analysis of Results 39
popular response was they thought that there were too many people in the
laboratory.
7. Do you have access to a computer and the Internet at home? This generic question was useful to see how many students had the basic
requirements to perform the exercise from home. Sixty-one students replied
‘yes’, five replied ‘no’.
8. After performing both tasks, do you think you would prefer to do task 1 locally or remotely? (Still handing in a formal lab report.)
After they had completed both tasks, the students should have had an idea of
how they would be able to perform the in class laboratory exercise on-line. This
question received thirty-one preferences for local control and seventeen for
remote control.
Table 5: Reasons why students preferred local control.
Option Number of Responses
Needed to see it working. 14
Need a lab demonstrator. 7
Prefer hands-on experience. 12
Easier collaboration between students. 6
Problems can be dealt with immediately. 3
Problems occurred with remote lab. 3
Remote software installation was a problem. 5
Need a lab report to understand concepts better. 1
Table 6: Reasons why students preferred remote control.
Option Number of Responses
Too many people in lab for task1 2
Can do in own time 6
Can use own computer. 1
Can work at own pace 1
Would require a camera. 2
This lab was suited to one person at a time. 1
The responses from students were interesting to find out why they preferred
local control. It is possible that when the students have a better understanding
Analysis of Results 40
of the Telelabs system, they will find out about the chat feature and will be able
to collaborate with that. Telelabs also has a feature for a supervisor to be
online and answer questions through a chat window. The most important
aspect was the need to see the rig in action. When the camera software has
been developed further, this may be an adequate substitute.
9. Do you think it is necessary to perform the lab on real equipment or do you think the simulation alone would provide the same experience?
This question was found by students to be badly worded, so they answered it as
if it were two separate questions. It was found that the majority of the students
preferred the real equipment for various reasons, most of these were so they
would be able to learn the extra things like effects from manufacturing flaws or
‘quirks’ with the design of the system. The most popular responses are shown
in Table 7.
Table 7: Reasons why students would prefer real hardware.
Option Number of Responses
Need real equipment 44
Badly worded question 6
Would need to be properly developed 3
A simulation is as good as the real thing. 7
10. Did you feel comfortable controlling the rig remotely? It is not desired for students to feel awkward controlling the hardware they need
for their experiment. This question was misinterpreted by some students
because of the word ‘comfortable’, but most of the students understood and
replied with fifty-three responses for ‘yes’ and thirteen for ‘no’. Table 8 and
Table 9 show the suggestions for why they chose the response they did.
Table 8: Reasons why students felt comfortable controlling the rig remotely.
Option Number of Responses
It was simple 23
Link from forum suggested for login 1
Interface looked the same so it was easy to use 5
Was comfortable, as Telelabs had been used before. 4
Analysis of Results 41 Table 9: Reasons why students felt uncomfortable using the rig remotely.
Option Number of Responses
Same as a simulation 1
It didn’t work 4
Need to visualise 1
Lost confidence due to erratic results 1
The next set of questions could be more valuable to the analysis, as the
students had a chance to compliment or complain as much as they liked. They
also had to think of the responses themselves because there was minimal
prompting, so these suggestions are closer to what the students actually feel.
These questions are all grouped together, as many of the responses were
intertwined in the answers. A discussion about the results follows the tables.
Table 10: What did you like about using the rig remotely?
Option Number of Responses
Can do it in own time. 21
Did not like it. 13
Got a chance to use it. 4
Not cramped like in the lab. 1
The controls were attractive. 2
It was simple to use. 5
It moves the hardware. 3
Could work at my own pace. 8
Could do it from home. 5
Table 11: What did you like about using the rig locally?
Option Number of Responses
Can see it move. 32
Ask demonstrator questions. 10
Realism. 7
Collaboration. 6
Hands on experience. 5
Hearing the motor response. 4
Working in a group. 1
Analysis of Results 42 Table 12: What did you dislike about using the rig remotely?
Option Number of Responses
Too long to download and install software. 10
No visuals. 14
Cannot ask questions. Need a lab demonstrator. 4
Nothing. 4
Waiting in the queue. 4
Table 13: What did you dislike about using the rig locally?
Option Number of Responses
Too many people in the lab. 25
Waiting for other people. 16
Watching people who do not know what they are doing. 3
Nothing. 10
Not enough time to get a good understanding. 5
Table 14: Can you think of anything we could do to improve the laboratory?
Option Number of Responses
Need smaller groups. 13
Have theory taught in lectures before it is taught in lab. 4
Inform about online part sooner. 7
Need a camera image. 7
Demonstrate in lectures and then perform experiment at home. 4
Column headings needed in emailed results. 2
Table 15: Do you have any other comments?
Option Number of Responses
Provide hands-on and remote lab with an option of which one to
do.
2
Labs on Line system does not promote communication or team
work.
1
The survey was too long. 1
The survey does not always submit correctly. 2
The survey should be anonymous to get students real opinions. 1
The remote lab by itself would be better. 1
The consensus from the students indicates that the reason for them preferring
the local control of the laboratory equipment was that they could not see the
Analysis of Results 43
hardware move. This problem will be solved for many students if video data
was provided, but may satisfy enough of them if an animation, image and good
explanation of what is actually happening was provided on the webpage.
Another major point of interest with the remote task was that students required
a demonstrator so they could work out how to use the system and could ask
questions if problems arose during the laboratory exercise. For task2, there
was no demonstrator, as there was no set time for them to perform the task.
Laboratory exercises held in the future will be able to use the supervisor
interface that has already been built into the Telelabs system.
Overcrowding in the in-class laboratory was mentioned many times. This is a
problem directly addressed by Telelabs. It would have been much better if the
classes were kept to minimum numbers. The students had the option of ten
sessions they could have gone to, the first few laboratories times were not fully
booked, and the last few were very crowded. This phenomenon will probably
transfer to the amount of time waiting in the queue for the remote exercise.
The last major ‘gripe’ that students had with the system was the downloading
and installing of the software. As notification about this problem was received
during the exercise, some distribution CDs were created that determined the
software for each computer and installed everything required automatically and
even put an icon on the user’s desktop. The students were notified that these
were available, but only five of the ten provided were used. As there was
limited time for the students, a software rollout was performed to all of the
machines in the computer laboratories in the Mechanical Engineering
Department.1 There were no more difficulties received by email after this.
There were positive comments that were received. Most of these were
comments that they were able to do the task in their own time.
These results indicate that the current direction of the Telelabs project is
correct, but still needs addition in some minor areas. 1 IT Support will probably know how to do this. It is recommended to mention Microsoft®
Installer (MSI) packages and Group Policies when speaking with them.
Conclusions
At the end of this project, it can be seen that completing the initial objectives
was slightly too ambitious and was not quite obtained. Much has been learned
however, and overall, this project has been a success.
The first objective was to provide an accurate simulation. This was not
completed, as two simulations were developed instead, which are not quite
finished. This objective would have been completed if only one of the
simulations was developed. Positive results from this can be obtained however,
as future students will be aware of the integral calculation problem with the
simulation toolbox and will be able to avoid it.
The second objective was to provide a stable hardware master. This objective
was achieved and exceeded by adding the ability for it to be run as a Windows®
service. The procedure for creating the service can be found in Appendix I.
An effective remote client was created and was tested by students. No client
related software failures were reported, except for installation related problems,
indicating that it is reliable. This objective has therefore been achieved.
Good progress with the development of a tele-vision system has been made,
but was unfortunately was not completed. When the transmission protocol is
changed to DataSocket, the software should provide an effective vision system
that will be portable to any network camera that uses ActiveX controls.
It was found that the camera was suitable for slow moving objects, but pointless
for use with fast moving objects. This was because the frame rate/bit rate quite
simply requires more than the current bandwidth than the Internet provides.
Testing of the system reliability was done during both the in-class laboratory
and the remote laboratory. Some problems were found during this testing, but
these have now been corrected.
Conclusions 45
The electronic survey was able obtain student feedback, providing some useful
indicators about the project. This feedback will prove to be invaluable for the
Telelabs project as it indicates the areas where students are having problems.
Most of these problems were related to students not being able to visualise the
hardware when used remotely. This indicates that a tele-vision system is
required. The other major problem was students were unable to unzip two files
to a specified directory.
Recommendations for Future Work 46
Recommendations for Future Work
The most important recommendation is to read the comments made by the
students and to address these as best as possible.
When the students performed their laboratory experiment, several hardware
faults were determined that will soon require attention. These caused
inconsistent results that made it difficult for students to understand the
properties of the controller.
The first problem noticed was the pointer is making contact with the frame in
one position. This changed the response of the system when the pointer was
operating in that range compared to when it was not operating in that range.
This is because the frame is twisted.
The second problem was a slight imbalance of the pointer. This was found as
the ideal parameters changed when the set point was vertical compared with
when the set point was horizontal.
The third problem was the angular velocity of the motor was different for anti-
clockwise directions compared with clockwise directions. This changed the
response of the system, which confused students.
Although this fault will not cause inconsistencies in results, it should be noted
that the pointer is cracked around one of the grub screws that mount the pointer
to the shaft. This looks like it was caused by over tightening of the screw and
may cause problems when the rig is overhauled. This in conjunction with the
pointer’s imbalance may mean a new pointer should be made.
For the laboratory next year, it is recommended that the technicians rectify
these problems, so there is not as much confusion.
Recommendations for Future Work 47
Many students asked questions over email about problems with the Java
simulation. This indicates that the LabVIEW simulations that were started with
this project should be completed and tested.
The simulation using the equations of motion requires the parameters to be
scaled to suitable units and the simulation controls cluster needs to have the
precision increased. After this has been done, the coding of the differential
equation can be tested. The remote client that this is contained in will then
need updating to the current version.
The problem with the control theory simulation is the LabVIEW integration
technique. This simulation could be recoded in a similar manner, except using
the Runge-Kutta module (Trevelyan 2001) and the PID controller (Davies 2002).
Another suggestion with the simulation is to check the gains that are used for
the transfer function. This is because the old gains are still in use even though
the circuit board has been rebuilt.
The network camera has the ability to be turned on and off remotely. This
would save considerable local bandwidth if this feature were incorporated into
the hardware master.
Changes to the structure of the camera software should be changed, so the
transmission protocol used is DataSocket instead of UDP. This is now the
chosen protocol as it automatically compensates for different connection
speeds. When the video streams are split, it may be easier to create individual
DataSockets for each stream.
The use of LabVIEW queues may not be as an attractive idea as they first
seemed. The reason for this is the images are not deleted from memory when
they are deleted from the queue, so the memory resources of the machine are
quickly consumed, causing system failure.
Recommendations for Future Work 48
When the software has been tested more thoroughly, the thread priority
problem caused by the camera software with the hardware master and remote
client could be addressed.
Some students mentioned that they would find the experiment more ‘real’ if they
could hear the motor. The AXIS2100 has an audio module that can be
purchased that integrates very easily into the camera control software.
A simple to understand explanation of the operation of the rig should be added
to the website. In addition, many students had problems with the derivation of
the response function required for the lab report, so this should also be
uploaded. An electronic copy of this can be found in Appendix V.
As the students were concerned about collaboration, it may be an idea to add a
voice transmission feature to the chat section of the Telelabs interface.
A student complained that they thought they were getting erratic results from
someone ‘hacking’ the system. After some thought, this may have been due to
other students in G19 playing around with the pointer while the student was
performing the remote task. It is suggested that the rig is placed in G21, so this
cannot occur.
References 49
References
Trevelyan J. 2002, Towards Cost Effective On-Line Laboratories, Networked
Learning Conference, Berlin.
Stoll S., Hopp C. 2002, Information Technology Online, Networked Learning
Conference, Berlin.
Marin R., Sanz P. 2002, Telerobotic Training System Through the Web,
Networked Learning Conference, Berlin.
Chang V., del Alamo J. 2002, Collaborative WebLab, Networked Learning
Conference, Berlin.
Chew A. S. 1997, Development of a Feedback System for Position Control,
Honours Thesis, The University of Western Australia, Perth.
Dalton B. 2000,Telerobotic Development, Ph. D. thesis, The University of
Western Australia, Perth.
Baranski J. 2000, SCADA System Development, Design Study, The University
of Western Australia, Perth.
Boden A. 2000, Telelabs Preliminary Investigation, The University of Western
Australia, Perth.
Davies T., Chan D. 2002, Network Cameras versus Streaming Video, Vacation
work project, The University of Western Australia, Perth.
National Instruments Knowledgebase [online] http://www.ni.com were the
source for the following PDF documents:
Building an Interactive Webpage with DataSocket.pdf
References 50
DataSocket for LabVIEW.pdf
DataSocket Technical Overview.pdf
AI-100 Calibration Procedure.pdf
FP-1600 Spec Sheet.pdf
FP-1600 User Guide.pdf
FP-1600-Quick Start Guide.pdf
FP-AI-100 Operating Instructions (2).pdf
FP-AI-100 Operating Instructions (3).pdf
FP-AI-100 Operating Instructions.pdf
FP-AI-100 Spec Sheet.pdf
FP-AO-210 Calibration Procedure.pdf
FP-AO-210 Operating Instructions.pdf
FP-AO-210 Spec Sheet.pdf
FP-DO-401 Operating Instructions (2).pdf
FP-DO-401 Operating Instructions.pdf
FP-DO-401 Spec Sheet.pdf
FP-TB-1 Spec Sheet.pdf
Control and Simulation Toolkit Reference Manual.pdf
Internet Developers Toolkit.pdf
Internet Toolkit Reference Manual.pdf
Axis Cameras knowledgebase [online] http://www.axis.com supplied the
following documents:
2100user_guide.pdf
AxisCamControl1031.pdf
AxisCamControl.doc
Internet Encyclopedia [online] http://www.freesoft.org/CIE/index.htm supplied
the following documents:
Postel J. 1980, RFC768,
Plummer D 1982, RFC826
Redman F., Rajan J. 1997, Human Factors for Safety-Critical Systems,
Appendix I
The Hardware Master as a Service
To allow students with different logins to use the runtime machine while it is
running the hardware master, a wrapper for the executable was configured.
This provides the ability for the service to be managed from a remote location.
To manage a service from outside the department, a minimum of local
administrator access is required through the department’s firewall.
1. Extract srvany.exe and srvinstw.exe from compmgmt.cab on the
Windows 2000 Resource Kit CD.
2. Rename srvany.exe to the name you would like to call the wrapper
service. For this example: Position HW Master Service Wrapper.exe.
3. Execute srvinstw.exe
4. Select “Install a service
The Hardware Master as a Service II
5. Select Local Machine
6. Type the Name for the service
The Hardware Master as a Service III
7. Enter the path to the service wrapper
8. Select Service is its own process
The Hardware Master as a Service IV
9. Use the system account to use the system user security settings
10. The service is to be started when the machine starts up, so select
Automatic
The Hardware Master as a Service V
11. Click Finish
You should receive a confirmation message
Then launch regedit
The Hardware Master as a Service VI
Navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Position
Control HW Master
Create a new Key
With the name: Parameters
The Hardware Master as a Service VII
Select the parameters key
Then create a new value
name it: Application
The Hardware Master as a Service VIII
Then modify this key
Close the registry editor
Right click “My Computer” and select “Manage”. Then you can configure the
service by using the Computer Management Snap in.
Navigate to your newly created service. Right click and select properties.
The Hardware Master as a Service IX
On the recovery tab, select the following options
The full console message to IT Support is “net send ashbrook The Position
HW Service failed to start.”
On the general tab, select start
The Hardware Master as a Service X
Click OK
Press Ctrl-Shift-Esc to bring up the Task Manager
The Hardware Master as a Service XI
Ensure Position HW Master Service Wrapper.exe and position hw
master.exe are running.
Rig Configuration on the LOL-Server XII
Appendix II
Rig Configuration on the LOL-Server
The following details are used for the creation of a rig, course and task entry on
the LOL server.
Rig Record
Rig ID 5 First free integer (others in
use)
Rig Name Position Control
Rig Comment
Position Control Experimental Rig
Fault Email
[email protected] Where emails are sent if
faults occur
Base URL Dstp://130.95.52.244/position The location of the client
library
IP Address
130.95.249.86 The address of the machine
running the hardware master
Rig Status OPEN (OFFLINE) Rig status for users
Reset Limit
1.00min The reset limit
Components of the Position Control Rig XIII
Appendix III
Components of the Position Control Rig
Figure 15: Representation of a potentiometer.
Figure 16: Differencing circuit used by the Position Control Rig.
Components of the Position Control Rig XIV
Figure 17: The PID circuit used by the Position Control Rig.
Figure 18: The servo-amplifier used by the Position Control Rig.
Figure 19: Representation of a gearbox.
Communication Protocols XV
Appendix IV
Communication Protocols
The Internet can use various means of transmission, but they are generally
based on the ISO OSI seven-layer model. This section discusses the protocols
used for this laboratory.
Ethernet The Ethernet protocol is a layer-two mechanism that converts an IP address
into a 48-bit Ethernet address. An address resolution module within the
hardware driver is checked to find this pair in a table. If it finds the pair, it gives
the corresponding 48-bit Ethernet address back to the caller’s hardware driver,
which then transmits the packet. The sender hardware address and sender
protocol address are necessary and these fields are reset in the translation
table every time the router or the machine containing the Ethernet card is
rebooted. If the pair is not found, the packet is broadcast and the driver on the
destination machine replies with an acknowledgment. The sender then updates
its table. If there is no reply, the packet is dropped as it is assumed that the
handling is done by a higher-level protocol. (Plummer 1982)
Internet Protocol IPv4 can address up to 2^32 locations IPv6 can address 2^128 locations.
Subnetting allows private networks to be configured so the flow of network
traffic between hosts to be segregated based on a network configuration. By
Communication Protocols XVI
organizing hosts into logical groups, subnetting can improve network security
and performance.
The model of operation is that an internet module resides in each host engaged
in internet communication and in each gateway that interconnects networks.
These modules share common rules for interpreting address fields and for
fragmenting and assembling internet datagrams. In addition, these modules
(especially in gateways) have procedures for making routing decisions and
other functions.
The Internet Protocol uses four key mechanisms in providing its service: Type
of Service, Time to Live, Options, and Header Checksum. The type of service
is a generalized set of parameters, which characterise the service choices to be
used by gateways to select the actual transmission parameters for a particular
network, the network to be used for the next hop, or the next gateway when
routing an internet datagram. The Time to Live is an indication of an upper
bound on the lifetime of an internet datagram. It is set by the sender of the
datagram and reduced at the points along the route where it is processed. If the
time to live reaches zero before the internet datagram reaches its destination,
the internet datagram is destroyed. The Header Checksum provides verification
that the information used in processing the internet datagram has been
transmitted correctly. (Defence Advanced Research Projects Agency 1981)
Calculating the Response Function XVII
Appendix V
Calculating the Response Function
( )1
o
o
HH sH
=+
where: 2
1o pot oA A T RH K K K K K
Js Bs=
+
2
22
( )1
pot oA A T R pot oA A T R
pot oA A T R pot oA A T R
K K K K K K K K K KJS BS JH s K K K K K K K K K KBSSJS BS J J
+∴ = =+ + +
+
let 3
24
(5.31 10 )( 0.08)( 2)(160) 271.9 /5 10
pot oA A T Ro
K K K K Krad s
Jω
−
−
× − −= = ≈
×
and 4
0.011532 0.6992 5 10 2 16.49o
o
B BJ J
ξω ξω −= ⇒ = = ≈
× × ×
then 2
22( )
2o
o o
H sS S
ωξω ω
=+ +
Using the partial fractions technique:
( ) ( )( )
222
2 22 2 22
2
2 2 2o oo
o o o o o o
A S S S BS CA BS CSS S S S S S S
ξω ωωξω ω ξω ω ξω ω
+ + + ++= + =
+ + + + + +
generates coefficients of:
Calculating the Response Function XVIII
112 o
ABC ξω
== −= −
so that 22
21( )2
o
o o
SH sS S S
ξωξω ω+
= −+ +
As ( )i tθ is a step function:
00
1( ) st st ioi io ios e dt e
S Sθθ θ θ
∞∞ − − = = − ∫ =
and ( ) ( )( ) ( ) ( ) ( ) ( )( )o i
o ii
s sH s s H s s H ss S
oθ θθ θθ
= ⇒ = =
( )22
2( )
2io oio
oo o
Ss
S S Sθ ξωθθ
ξω ω+
∴ = −+ +
Applying an inverse Laplace transform:
[ ] ( )1 1 122
2( ) ( )
2io oio
o oo o
St L s L L
S S Sθ ξωθθ θ
ξω ω− − − + = = − + +
( ) cos sinot oo io io d d
d
t e tξω ξωθ θ θ ω ωω
− = − +
t
where 21d oω ω ξ= −
manipulating to the same form as used in the simulation:
( ) ( ) ( ) (( ) 1 exp 11.5 cos 11.79 0.977exp 11.5 sin 11.79o
io
t t t t )tθθ
= − − − −
The simulation without compensation gives a similar answer of:
1.000 - 1.000Exp(-11.530t)*Cos(11.787t) - 0.978Exp(-11.530t)*Sin(11.787t)