using matlab to create cheap and accessible virtual...

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: [email protected]

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


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.


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.


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.


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


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


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).


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).


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.

using matlab to create cheap and accessible virtual...

Documents