using matlab to create cheap and accessible virtual...
Post on 26-Jun-2020
3 Views
Preview:
TRANSCRIPT
4th International Symposium for Engineering Education, 2012, The University of Sheffield, July 2012, UK
Using MATLAB to create cheap and accessible virtual laboratories
J.A. Rossiter
University of Sheffield
Abstract: It is well known that laboratories benefit student learning, but access is
severely restricted in practice due to timetabling and other constraints. Consequently a
major aim of this paper is to propose mechanisms for augmenting students’ practical
activities without requiring them to enter a timetabled laboratory. Within the community
this is often done with remote access laboratories and also so called virtual laboratories,
that is laboratories that in fact are simulation only. The advantages of virtual laboratories
are manifold, for example the whole class can access them simultaneously and of course
they are cheap and often more flexible which means that staff can embed more interesting
activities and learning outcomes than are possible with laboratory equipment. This paper
will place some focus on the staff facing part of virtual laboratories, that is the design and
coding of the activities. Most staff are busy and not computer experts and therefore
coding complex scenarios is infeasible in general. However, it will be shown how the
MATLAB/SIMULINK tool facilitates quite complex scenarios with relative ease of
coding. Moreover, the software includes animation tools which are relatively simple to
use and thus make the ‘activity’ feel more authentic. Several case studies are discussed in
terms of the coding required to produce them and their fit into the curriculum.
Keywords; MATLAB, virtual laboratories, engagement, authenticity
Correspondence to: J.A. Rossiter, Department of Automatic Control and Systems
Engineering, University of Sheffield, Mappin Street, S1 3JD. E-mail: j.a.rossiter@shef.ac.uk
1. INTRODUCTION
A lot of work has appeared in the literature discussing the importance of laboratory and practical
activities to help students both develop more practical skills as well as to give some authenticity
of their learning (Abdulwahed 2010). However, it is equally recognised that laboratory provision
is expensive and consequently there are severe limitations on both space and equipment.
Combine this observation with increasing student cohorts and this also results in significant
timetabling pressures with the consequence that typical engineering students do not get the hands
on activity that would ideally be provided.
1.1 Remote access laboratories
One obvious solution to this dilemma is to pursue the potential of remote access laboratories
(RELOAD 2010, Qiao et al 2010, Rossiter et al 2011, etc.). Such laboratories can, in principle,
be accessible 24/7 and thus hugely increase availability to students of real hardware and real
data, as well as opportunities for students to reflect and then learn through trial and error or
experimentation. Nevertheless, a less well publicised problem with web laboratories is that they
too can be very expensive to provide and the maintenance requirement can be substantial. It is
critical that the laboratory has good availability during periods that students should be using it
4th International Symposium for Engineering Education, 2012, The University of Sheffield, July 2012, UK
and this can mean technical staff monitoring the equipment regularly (say every hour or more
often); even this does not mitigate against overnight failures. Remote laboratories that are not
very reliable lead to frustrated students and worse rather than better student experience.
1.2 Virtual laboratories
Other popular alternatives in recent years are the use of so called virtual laboratories, animations,
videos and other technology facilitated means of interaction. The fundamental point is an activity
which has more ‘authenticity’ then say paper/pen exercises [Khan et al 2006, Foss et al 2006,
Goodwin 2010] and in particular encourages student interaction and engagement.
Virtual laboratories have several advantages over hardware laboratories such as:
1. Parallel access is possible, often by hundreds of students simultaneously.
2. 24/7 access is straightforward and these are much less susceptible to failure.
3. Can be far cheaper to produce and also far more flexible in terms of the learning
outcomes to be assessed and reinforced.
However, one significant obstacle to the wide take up of virtual laboratories is the skills
requirements (Pearce 2008, Guzman et al 2006). The computer skills requirement to produce a
good remote access activity, say via the web, can be significant and thus involve computer
experts. Certainly the time requirement will be well beyond what a typical academic is able to
give, even in the rare case that they have the relevant computing expertise.
1.3 Summary
This paper makes the assumption that laboratory based and other interactive activities are an
essential part of an engineering education and considers to what extent staff can reasonably
provide these. In particular the focus is on reasonable development time and effort for staff in
conjunction with good access and reliability for students. The author makes the argument that
being able to code these in readily available wysiwyg type software will reduce the time and skill
requirements on staff. If this can be combined with software that is readily available to students
then it is possible to make significant progress. In the author’s case, the software of choice is
MATLAB (www.mathworks.co.uk) because:
1. It is readily available on the University network and indeed students can acquire this at
very preferential rates for their own use.
2. MATLAB use is embedded elsewhere in the curriculum so students are familiar with it.
3. The GUI tool in MATLAB is wysiwyg, that is coding is straightforward and relatively
quick. This includes relatively transparent access to the requirements for adding
animation effects.
Section 2 will give a quick overview of how to code virtual laboratories in MATLAB and section
3 will then give a number of examples of these, along with some discussion on how they might
be integrated into the curriculum.
2. CODING VIRTUAL LABORATORIES IN MATLAB
Matlab includes a tool for making ‘Graphical User Interfaces’ (GUIs). The nice thing about this
tool is that it requires a very low level of coding expertise to make relatively advanced interfaces.
4th International Symposium for Engineering Education, 2012, The University of Sheffield, July 2012, UK
2.1 Learning outcomes
Naturally a module leader begins from an assessment of the learning outcomes; what exactly do
they want students to learn or skills should they develop and hence what form of activity will
support this effectively. Having been clear on this, the lecturer will begin to think about what
format an interface might take including aspects such as:
1. What figures and animations should the student see?
2. What decisions should the student be able to make?
3. What other buttons might improve the student learning or interaction with the interface?
From questions such as these, the lecturer can relatively quickly come up with a rough paper
sketch of how the interface will look and also a clear definition of what engineering lies beneath
each artefact on the interface. This lower level will be used to help define coding requirements.
2.2. Building the graphical interface
The guide environment has a number of ready made artefacts which meet most conventional
needs: (i) sliders; (ii) text boxes; (iii) axes; (iv) choose from a list; (v) action buttons; (vi) etc.
The sizes and colours of these can be modified directly in the guide environment using a
transparent properties interface. Similarly, the overall GUI size is adjusted using a simple mouse
action as with standard windows. Consequently, once the lecturer has a draft on a piece of paper,
translating this onto guide can be done in literally a few minutes. An example of the environment
is given in figures 1,2 which shows the GUI design window and also the properties window for
modifying colours, font styles, etc..
Figure 1 The guide environment on MATLAB with some artefacts.
4th International Symposium for Engineering Education, 2012, The University of Sheffield, July 2012, UK
After just a few minutes work on styling, this will produce an interface as shown in figure 3; this
is deliberately a bit garish to demonstrate the point. This very simple GUI includes a slider with a
matching numeric display in the box alongside – the user can edit either to enter the desired
value. A popup menu which essentially contains a list of desirable actions: for example this
could be closed-loop or open-loop simulation. The push button can be used to say ‘simulate
now’, that is when all the USER choices are set as desired. The results appear on the graph.
Remark: There is one warning. MATLAB assigns a unique handle or tag to each artefact. These
follow a logical ordering which can be lost when the user deletes artefacts and then creates more
similar ones. It is recommended that the user tries to get the interface right first time as this has
obvious coding advantages in terms of writing and understanding the related code. For example,
try to ensure that slider1 is paired with edit1, slider2 is paired with edit2 and so on.
Figure 2 Transparency and modification of artefact properties.
2.3. Coding requirements
Having constructed the interface and selected save and a partner m-file is produced. The m-file
has a simple structure which is easy to work with once the user learns to ignore all the automated
comments that are inserted to help the author.
1. Opening and closing functions are linked to the basic GUI set up and display. An amateur
programmer, such as indeed the author of this paper, are best to leave these alone and
assume Mathworks know best what should be in here. However, any initialisation that is
required could be inserted in here, such as setting up a default graph display.
4th International Symposium for Engineering Education, 2012, The University of Sheffield, July 2012, UK
2. Each artefact will have an associated subfunction with the a title something like:
pushbutton1_callback or pushbutton2_callback or slider1_callback, etc. This title is a
combination of the artefact handle or tag and the work callback.
3. The callback subfunctions operate whenever the associated artefact is modified by the
user so it remains only for the author to decide what action is required when an artefact is
modified. For example in figure 3 typical actions could be:
a. If the slider artefact is moved, update the associated number in the edit text box to
match.
b. If the edit text box is modified, update the slider to match.
c. If the popupmenu is modified, do nothing.
d. If the run button is selected, find the current value of the slider and popupmenu
and use this information to produce the relevant graph.
Figure 3 Example of final interface.
Extracting the values stored in the artefacts is straightforward because, behind the scenes, the
programme automatically stores all these values in a variable that is accessible in all the
subfunctions. In simple terms;
1. The variable handles contains the link to all the artefacts, so for examples handles.slider1
is the link (or handle) for artefact slider1.
2. Properties of an artefact (which can include colour, fonts etc.) are extracted using the get
command which has an obvious and simple syntax. A typical example for finding the
current position of a slider would be: get(handles.slider1,’value’);
2.4. Adding animations
The more difficult task is to add animations to a GUI and this sense of something moving brings
a lot more authenticity to the activity than simply selecting numbers and strings in order to see an
updated graph. MATLAB does contain advanced animation capabilities, but for a staff member
4th International Symposium for Engineering Education, 2012, The University of Sheffield, July 2012, UK
wanted a simply and fast means of creating these, the authors has found a very simple and
effective mechanism works well enough. The basic technique is as follows:
1. Use a loop to update the relevant graphics.
2. Enter a pause in the loop so the updates happen at a prescribed rate.
A simple example in table 1 will show how easily this can be done, for example with a line
graph. A line graph has 3 key properties, the data on the horizontal axis (denoted Xdata), the
values for the vertical axis (denoted Ydata) and which axes is this plotted in (some GUIs have
several axes).
Code Interpretation
Xdata= get(handles.axes1,’Xdata’);
Ydata= get(handles.axes1,’Ydata’);
Xdata=[Xdata,newx];Ydata=[Ydata,newy];
set(handles.axes1,'Xdata',xx,'Ydata',yy);
Collect current Xdata and Ydata from axes
with handle handles.axes1.
Add new values to the data.
Update the sketch.
Table 1: Example of how to update a line graph with additional values
In general a graphic may contain more complex animations but the process is the same. Typical
functionality that might provide useful and very simple to use is listed in table 2; obviously this
is a brief list for illustration only and many other examples exist.
Code What this does
fill(x,y,’Color’)
annotation(gcf,'arrow',x,y)
text(x,y,’string')
Fills a shape with vertices x,y in specified
colour. It is easier to modify both the vertices
and colour using the set command.
Draws an arrow with start and end points in
x,y. All properties can be modified, e.g. start
and end point, thickness and colour.
Puts a specified string in position x,y. String
and position can be changed.
Table 2: Examples of other useful objects that can be modified in an animation.
3. EXAMPLES OF VIRTUAL LABORATORIES
This section will briefly describe some of the virtual laboratories that have been developed and
used by the author.
3.1. Tank level modelling and control
Many students find control as a topic somewhat mathematical and abstract and thus it helps to
bring some examples into the lecture theatre, and indeed the students homes, that they can relate
to easily. Tank level control is one such example as students can easily related this to filling a
bath or other container and can have a natural feel for the impact of increasing or decreasing the
flow rates into and out of the tank. Hence, this GUI was designed to help them understand the
role of PI (proportional and integral) parameters in automating the decision making on flow into
the tank while giving some movement to help them see the impact in pseudo real time. Figure 4
shows two screen shots, one with high PI values and one with low values. It is clear that the
4th International Symposium for Engineering Education, 2012, The University of Sheffield, July 2012, UK
former case gives a large input flow whereas the latter gives a low flow; the animation shows the
flow changing in real time, as well as the depth changing appropriately. Line graphs capture the
whole simulation.
Figures 4a,b: Screen shots from the tank level animation
In terms of coding, the main requirements aside from basic GUI presentation are:
• Define the lines which give the tank and the vertices for marking the initial water level.
• Set up a loop for the feedback control which updates flow and outputs several times a
second.
• At each point in this loop, update the liquid and flow by updating the vertices
appropriately and update the line graphs.
The reader will note that the basic coding requirements are not therefore, overly demanding.
3.2. Housing temperature modelling and control
This animation also has a dual role of helping students understand the modelling of temperature,
using simple assumptions and then how a control law can be used with this. Here, the house
changes colour gradually as it goes hot or cold (bright red if too hot, blue if too cold). The line
graphs give an overview of the efficacy of the chosen law with the specified house parameters,
all of which can be altered easily in the GUI. The coding requirements are very similar to the
tank level example except here colour is used rather than changing vertices.
3.3. Modelling passenger comfort in a landing aircraft
In this case the students see the man in a seat move from the top left of the screen to the bottom
right, to emulate a landing aircraft. As contact is made with the ground, the spring and dampers
move (contract and expand) as expected. This movement will change as the students change the
choices of spring stiffness, mass and damping. The main coding is to ensure that the man in the
seat moves at constantly velocity from left to right (constant change in Xdata for all objects),
while superimposing the relevant vertical motion of the different components. Some care is
needed here as the base, middle and top of the spring move through different distances as it
extends and contracts (vertical velocity is proportional to height above the ground).
4th International Symposium for Engineering Education, 2012, The University of Sheffield, July 2012, UK
Figures 5,6: Screen shots from the house temperature animation and landing aircraft
3.4. Further developments and remarks
The examples presented in this paper are, by design, simple because the main usage is to
reinforce learning of core concepts for year 1 students and there is a deliberate choice not to add
in too many issues which reflect reality, such as noise, non-linearity, etc. because it is recognised
that year 1 students easily become confused if too many concepts are included at once. However,
for staff wanting to develop such activities for higher level modules it is of course
straightforward to develop these GUI tools to be more realistic and indeed access an underlying
simulink model containing detailed non-linearities.
Within the author’s department, we do have assignments where a virtual laboratory is used for
preparation activities, which thus first reinforces core concepts and then students use the actual
kit later which encourages reflection on what is different in the real world.
4. CONCLUSIONS
This paper has shown how virtual laboratories which, albeit amateur to some extent, can be
constructed relatively quickly in MATLAB and made readily available to students. As these are
coded in house the only price is staff time and moreover they can be tailored easily to the
author’s requirements. The author has used these extensively over the past few years to brighten
up lectures and also to give students a more authentic learning experience for assignments.
5. REFERENCES
Abdulwahed, M, 2010, Towards enhancing laboratory education by the development and
evaluation of the trilab concept, PhD Thesis, University of Loughborough
Foss, B.A., Solbjoerg, Ole K., Eikaas, T.I., Jakobsen, F., 2006, Game play in vocational
training and engineering education, Advances in Control Education.
Goodwin, G. (2010). Virtual laboratories for control systems design. http://www.virtual-
laboratories.com/(last checked 1/9/10).
4th International Symposium for Engineering Education, 2012, The University of Sheffield, July 2012, UK
Guzman, J., Astrom, K., Dormido, S., Hagglund, T., and Y., P., 2006, Interactive learning
modules for pid Control, Advances in Control Education.
Khan, A and Vlacic, L, 2006, Teaching control: benefits of animated tutorials from viewpoint of
control students, Advances in Control Education.
Pearce, D., 2008, Impact of Animated Visual Models in Enhancing Student Understanding of
Complex Processes, Engineering Subject Centre teaching award
Qiao, Y., Liu, G., Zheng, G., and Luo, C., 2010, Design and realization of networked control
experiments in a web-based laboratory, Proc. UKACC.
RELOAD, 2010, Real labs operated at a distance, http://www.engsc.ac.uk/mini-
projects/reloadreal-labs-operated-at-distance (last checked 1/9/10).
Rossiter, J.A., Shokouhi, Y.B., Abdulwahed, M., Hammond, I. and Bacon,C., 2011, Developing
web accessible laboratories for introductory systems and control using student projects, IFAC
world congress.
top related