Remote controlled experiments for teaching over the Internet: A comparison of approaches developed in the PEARL project

REMOTE CONTROLLED EXPERIMENTS FOR TEACHING OVER THE INTERNET: A COMPARISION OF APPROACHES DEVELOPED IN THE PEARL PROJECT Martyn Cooper Institute of Educational Technology Open University, UK [email protected] Alexis Donnelly Department of Computer Science Trinity College Dublin, EIRE alexis.donne[email protected]e Jose Ferreira Departamento de Engenharia Electrotécnica e de Computadores Faculdade de Engenharia da Universidade do Porto, PORTUGAL [email protected] Abstract The PEARL project has been developing approaches for enabling real-world experiments to be conducted by students working, remotely from the laboratory, over the Internet. This paper describes these approaches and compares and contrasts three specific implementations of them both at the level of the nature of the practical work they support and the technical infrastructures that enables this to be conducted remotely. Initial evaluations by experts and representative student subjects are reported and key lessons for further development work by the project consortium, or others seeking to implement remote experiments, are outlined. Among the lessons learnt is that engineering realities associated with the equipment being used were difficult to accommodate in the generic architecture we initially envisaged. In fact the three implementations described adopted different architecture in their realisation of the PEARL approach. These are commented on in the paper together with notes on their implementation given available technologies. Keywords Educational Technology, Remote Experiments, Internet, System Architectures, Evaluations, Science Education, Engineering Education Introduction The PEARL project has been researching approaches for enabling real-world experiments to be conducted at a distance over the Internet. Four specific realizations of remote teaching practicals have been implemented and initial evaluation work undertaken. This paper compares and contrasts three of these implementations, both at the level of the type and nature of the practical work they support, and the technical infrastructure over which control and communications mediated. The fourth implementation at the University of Dundee essentially adopts the same systems and user interface architecture as at the Open University but is yet to be evaluated with end users so is only mentioned in passing in this paper. Firstly the PEARL project is described and its rationale given to set the paper in context. Introduction to the PEARL Project The PEARL project (Practical Experimentation by Accessible Remote Learning) started in March 2000. Cooper, et. al. (2000a) introduced the project in detail; only a brief introduction is included here. The PEARL project objectives are: • To develop a flexible system enabling students to conduct real-world experiments remotely via the WWW. • To research the pedagogic impact of this approach validating its developments in different educational contexts and subject areas in higher education. Key results of the project are four instantiations of the PEARL approach, one at each of the participating universities, providing teaching experiments in the following subject areas: • Foundation level science (Open University) • Manufacturing engineering (Trinity College, Dublin) • Electronic engineering (Faculty of Engineering, University of Porto) • Cell biology (University of Dundee) These are realized through a systems integration of: a remote controlled lab facility, a control and communications infrastructure working over the Internet, an accessible user interface sub-system and synchronous collaboration tools. A key deliverable planned is a PEARL Handbook designed to enable other institutions to adopt the PEARL approach in their teaching. PEARL is a major project with a total effort over the 3 years in excess of 30 person years and a budget of about US $2 million. The project is now entering its main validation phase with the technical development work being largely complete. Interim trials have been undertaken with student subjects using the prototypes, some of the findings of these are reported here. The full evaluation of the prototypes in real educational contexts takes place throughout the autumn of 2002. The project is due to finish at the end of February 2003. Rationale Experimental work is a vital part of science and engineering teaching at all levels. There is increasing use of multimedia science education packages and "virtual science" in both school and university level education. These approaches have great value if done well, however they generally focus on the teaching of science facts and principles and not the teaching of the process of scientific enquiry or engineering practice. Introduction to the working methods of the “community of practice” (Wenger et. al. 2002) is a stated objective of practical work in higher education in these subject areas. A key objective in PEARL is to create a Computer Based Learning (CBL) facility for learning science and engineering as a process. Access to experimental work in distance education has traditionally been achieved by including simple home experiment kits or intensive residential schools as part of the course. The PEARL project is seeking to facilitate wider participation in experimental work in distance learning courses and to make this available throughout the course. Other benefits of access to remote experiment equipment include: • For campus-based universities, the ability to circumvent space and time constraints in existing facilities as student numbers increase. • For universities in emerging economies, the ability to serve a large number of students from a single central facility. • For students and prospective employers, the ability to expose students, while still at university, to complex and expensive equipment (e.g. electron microscope) that they otherwise would not use • For students with disabilities, the possibility of using equipment with unsuitable interfaces or located in inaccessible laboratories, since many can now use computers equipped with suitable assistive technologies. In many countries this is now a legal requirement, and in fact was one of the original motivations for PEARL. The distinction between distance learning and traditional university learning is blurring with the rapid increase in Internet based course delivery. However there is widespread concern about the quality of the educational experience offered in some current Internet based courses. The PEARL system supports high quality science and engineering courses by enabling practical work to be integrated with other Web based or multimedia based teaching material. The pedagogy behind the PEARL experiments is underpinned by Laurillard’s Conversational Model (Laurillard 1993). In this model students develop their own model of the world (of the experiments) based on interactions with the experiment equipment, with their peers and with the demonstrator / lecturer. Thus the integration of computer based collaborative tools as well as the remote control of the apparatus is seen as particularly important. Description of the PEARL project's remote experiments This section gives a description of the remote experimental facilities created in the PEARL project and the practical work they are designed to support. These are compared and contrasted in the subsequent sections of this paper from the perspective of their rationales, learning objectives and technical approaches. Overview of the Open University experiment A series of linked experiments normally conducted by students at the Open University (OU) on a Summer School has been selected for conversion to a Web accessible form. The photo in Figure 1 shows the experiment jig for one of these experiments, developed by project partners Zenon S.A. of Athens. A simple optical spectrometer has been adapted so that it is motor controlled. Figure 1: Annotated Photograph of Motorized Optical Spectrometer Jig for the OU Experiment This experiment is designed to introduce students to the concept that different chemicals produce characteristic optical spectra and to demonstrate some of the physics behind optical spectrometry. Firstly they are introduced to the apparatus that they then have to calibrate using a sodium lamp as a reference source. They then go on to observe and measure the wavelengths of the spectral lines produced when four different chemicals are introduced into a Bunsen flame. This activity is combined with others to form a whole day’s session of related work. The apparatus to conduct these other activities remotely is also being developed in the PEARL project based on a programmable, desktop robot. This further facility is outside the scope of this paper as it is yet to be evaluated. Overview of the Trinity College Dublin experiment The Trinity College Dublin (TCD) computer vision experiment is depicted in Figure 2 below. It consists of an XY table (on which is mounted a printed circuit board to be tested later by automated visual inspection, plus some objects to assist with calibration), a camera and some controllable illumination sources. The camera can be zoomed, focused, panned and tilted together with some other functions to Telescope Camera Telescope Moveable Table Diffraction Grating Motor Rotating Telescope Shielded Na Lamp Shielded Bunsen Burner Gas Bubblers control exposure. Light sources are directed at the XY table and can be switched on and off only in this experiment. Two threaded shafts powered by electric motors drive the XY table. Figure 2: Annotated Photograph of TCD Computer Vision Experiment Rig Several computer vision experiments can be performed using the equipment depending on the objects placed on the XY table. In the validations reported here, students worked with a printed circuit board and some colour patches together with a chessboard-like pattern for calibration purposes. After a familiarisation period with the equipment, students use the pattern (of known dimensions) to calculate the focal length of the camera. Using this information, the size of features on the PC board can be determined. The students then, by trial and error and based on earlier lecture material, acquire an image of a suitable region of the board for image processing. Using MATLAB image processing software, they then apply a technique known as template-matching to locate components identical to that in the template. Another experiment, again using MATLAB, directs the students to determine if the camera sensor responds linearly to increasing levels of illumination. Rationale and Learning Objectives The amount of time for experiments in computer vision courses is sometimes limited by (lack of) equipment and staff time - depriving students of valuable hands-on learning experience. In a typical industrial setting where automated visual inspection techniques are used at the end of a production line, speed and accuracy of inspection are critical. The TCD PEARL experiments are designed to help students learn basic camera optics and performance characteristics together with image processing algorithms. Based on these understandings, students should, later in the course, be able to trade engineering concerns off against each other to optimise performance of automated visual inspection without sacrificing accuracy. Thus, by exploiting suitable illumination and camera performance, image processing time can be reduced without significant loss of accuracy. Overview of the Porto Experiment The electronics design and test remote lab, developed by the Faculty of Engineering at the University of Porto (FEUP), is in the form of a remote workbench offering full access via the web. The three experiments currently available using this facility share a common look-and-feel interface, which varies only according to experiment-specific control / observation facilities. Camera Printed Circuit Board XY Table Motors Light sources The access protocol is the same for the microcontroller and the introductory logic design experiments and includes the following steps: i) Implementation of the functional specification presented in the lab script (code design or hardware design, according to the type of experiment), which is carried out off-line; ii) Design verification by simulation, still off-line; iii) Connection to the remote lab server; iv) Design upload (code or schematic), remote hardware reset and set up. The third type of remote experiment supported, by this instance of a PEARL experiment, addresses the test of digital and mixed-signal circuits. While sharing the same user interface design and collaborative learning facilities, all the steps are performed on-line (because all test actions are carried out using an interactive application integrated in the user interface). A set of interim trials have already been conducted in relation to this type of experiment, providing a rich volume of data on pedagogical and technical aspects, including the implications of collaborative learning tools over the network traffic and effectiveness of learning. The importance of teamwork in the effectiveness of the learning process should be stressed, as became readily evident from the questionnaires filled by the students during the interim trial period. This is a well-known fact in cognitive studies and should be taken into account either in remote experimentation or in simulation-based experiments (Joolingen, W.R. van 2000). However, the introduction of collaborative work features calls for specific pedagogical skills, which frequently go well beyond the technical competence required for the design of (remote) experiments. Script design should therefore be seen as a multidisciplinary activity oriented by technical and pedagogical requirements, particularly when an increasing number of web-based communication and collaboration tools are widely available to improve the outcome of the authoring process. Comparison of the rationales and learning objectives of each experiment In Table 1 below, the three experiments of the PEARL project described here are compared in terms of their educational objectives categorised as content objectives and process objectives. This illustrates how the PEARL approach can be used to create remotely accessible experimental facilities not only in diversity of disciplines but with differing types of learning objectives. A high degree of interactivity between the student and the lab is achieved as well as effective collaboration between the students and their peers or tutors being supported. These are considered essential to meet the pedagogic objectives of the project. It is only when reflection is made on what the students observe that learning takes place. Content Objectives Open University Trinity College Dublin University of Porto To help students identify objects and phenomena and become familiar with them Identify and become familiar with light spectra Identify features of the rig and control them Response of camera to light intensity and frequency To help students learn a fact or facts Not a primary objective Not a primary objective Not a primary objective To help students learn a concept Each element emits light with a characteristic light spectrum Template matching Focal length To help students learn a relationship Grating relationship: d sin θ = n λ Relationship between zoom setting and focal length Relationship between camera response and light intensity and frequency To help students learn a theory or model Theory of image processing Equation relating measurements to focal length Camera response in context to light intensity and frequency Theory related to the use of test infrastructure Process Objectives Open University Trinity College Dublin University of Porto To help students learn how to use a standard laboratory instrument or to set up and use a standard piece of equipment Set up and use optical grating spectrometer Use Camera Use control applets for Camera Use XY-table and lights Boundary Scan Controller (an instrument able to control and observe a circuit board infrastructure compatible with the IEEE 1149.1 (.4) Std. To help students carry out a standard procedure Calibration of spectrometer using light with know wavelengths Use of calibrated spectrometer to measure unknown wavelengths Acquire and process image from the camera Process image Calibrate focal length Check linearity on camera sensor Scan in instructions Scan in/out data from the Unit Under Test (UUT) To help students learn how to plan an investigation to address a specific question or problem Later in the course students will be required to design an imageprocessing system to detect faults on PC boards In real world scenario student may be asked to perform a generic task and then devise the sequence of commands and the instructions/vectors to shift into the registers that are part of the test infrastructure To help students learn how to process data Processing of calibration data Use of calibration date to calculate unknown wavelengths from diffraction angles Use MATLAB routines to perform template matching Calculate focal length Check linearity Students have to interpret the values shifted out from the test registers To help students learn how to use data to support a conclusion Measured wavelengths allow students to deduce which metal ion is present in the a solution Whether the camera is responding linearly to light intensity To help students learn how to communicate the results of their work Not a primary objective Not a primary objective Not a primary objective Table 1: Comparison of the objectives for the 3 PEARL experiments described here Comparison of the Technical Approaches adopted to realize the three remote experiment facilities All PEARL experiments are based on a remote lab architecture that includes three main server-side components: the web server, the lab server and the laboratory equipment. The other core component is the client software, which is an application on the students PC, or an applet running the student's browser. There has also been extensive work on the user interface approach adopted in the project but this is outside the scope of this paper. Further detail is given in other publications (Cooper et. al. 2000b and 2002). An Apache based web server has been used to serve the experiments developed to date. However this is not an implementation requirement. FEUP use their web server to host the course management and delivery software, WebCT. The lab server processes all the actions / requests from the user, and communicates via local area network with the lab server. This second machine interacts with the laboratory equipment, either directly or via a dedicated communication and control bus as best suited to the particular lab equipment. As the PEARL project explored the technical issues towards the specific implementation of an architecture to meet the requirements of each experiment being developed it became apparent that there was no one optimal architecture. Therefore there were different approaches adopted at the four test sites. Although there are 4 separate implementations there is a fair amount of commonality, and indeed convergence to what might be termed a flexible PEARL architecture is ongoing. Commonality and divergence of approach The outline system architecture known as “the PEARL Approach” is shown in its two principle guises in Figure 3 and Figure 4. It is divided into three functional blocks usually implemented on separate computers. The Lab Server is connected directly to the experiment equipment and runs a program, perhaps proprietary, that exports a CORBA IDL interface. This interface may be invoked remotely from other computers on the Internet, including the web server. The connection between equipment and lab server machine is not important and will in practice be dictated by the equipment connected. Once the associated controller software exports a CORBA IDL interface (or can be made to do so) the actual details are effectively encapsulated as far as the rest of the system is concerned. The web server machine usually acts as a gateway to the lab server, providing additional security. The web server also stores lab scripts and implements authentication, scheduling and logging functions. The client machine typically runs a Java enabled browser to access learning material and execute applets that control the equipment. Figure 3: Outline System Architecture of the PEARL Approach (as implemented by TCD) Figure 4: Outline System Architecture of the PEARL Approach (as implemented by OU and UD) In the case of the TCD experiment, unlike the OU and UD experiments, interaction between Client and web server is only by HTTP. This choice was dictated by the reality that students would be accessing experiments from home over a telephone modem and an Internet Service Provider (ISP). In this situation, CORBA invocations made from the client might not work through ISP firewalls. The video-stream from the camera had to be sub-sampled to accommodate the narrow bandwidth available to the client. An added complication was that images had to remain detailed enough for subsequent image processing. Since in the TCD implementation all equipment operations were mediated through the web server, it was a straightforward matter to implement logging. Technical implementation and Systems Architecture of the OU Experiment This section presents an overview of the PEARL system focusing on the realization of the OU's Spectrometer Experiment. Figure 5 shows the architecture schematic of the remotely accessible spectrometer. The spectrometer has been mounted on a moving table so that the students can position it in front of different light sources. As configured in Figure 1, these are a Sodium (Na) Lamp, which is used to give a reference spectrum to calibrate the spectrometer and a Bunsen burner. Air is bubbled through one of up to 6 different metal salt solutions, as selected by the students, and into the gas feed to the Bunsen burner. Therefore the spectra associated with the chemical in each bubbler can be observed. The slit size and focus of the collimator, used to ensure the light is parallel as it passes into the diffraction grating, have been motorized, as has the rotation of the telescope. The students observe the jig via three camera feeds: one giving an overview of the jig in its setting, the second giving the view through the telescope to Experiment Equipment Lab Server Web server Client Experiment Equipment Lab Server Web server Client observe the spectral lines, and the third enabling the students to measure the rotation of the telescope by viewing its vernier scale. The driver circuitry for all the motors, valves and sensors is located together in a dedicated housing. This in turn is interfaced to the Motion Controller Board installed in the PC indicated as providing the Hardware Access, as shown in Figure 3: Outline System Architecture of the PEARL Approach, earlier in this paper. The Server application implements the high-level control operations that can be requested remotely. These high-level operations are translated to calls to low-level control methods exposed by the Hardware Access application. The low-level methods are invoked across a local CORBA bridge. The Server and the Video Transmitters interact, to allow the synchronization between the execution of control operations and the transmission of video, when necessary. This interaction is also achieved via local CORBA bridges. The Hardware Access application embeds the hardware-access ActiveX control and exposes its low-level control methods to the Server via CORBA. These low-level methods access the control routines that run inside the central processing unit (CPU) of a motion controller board [model DMC-18x2] from Galil Motion Control, Inc. installed in a PC. These routines control the actual jig's hardware, which consists of motors, sensors and valves, via the motor drive circuitry. For development and test purposes, the Hardware Access also includes a Simulation ActiveX control, which allows control of a simplified hardware model, rather than the actual Jig's Hardware. The Hardware Access can run on a different computer from the Server. Figure 5: Architecture schematic of the remotely accessible spectrometer The Video Transmitter application, based on the JMF package, can be instantiated once for each available Video Camera. Video is captured from the corresponding Video Camera and then processed. A video stream is transmitted to each connected Client. The video streaming uses the Real-Time Transport and the Real-Time Control protocols (RTP and RTCP). Each instance of the Video Transmitter can run on a different computer from the Server. All the CORBA bridges were based on version 4.0.5 of ORBacus for Java and ORBacus for C++ implementations of the CORBA standard, from IONA Technologies, Inc. The Client, Server and Video Transmitter applications are being developed in the Java programming language, in the Java 2 Platform, Standard Edition (J2SE) from Sun Microsystems, Inc. The Hardware access application is being developed in the C++ and Microsoft Visual Basic languages. The overall approach to the systems architecture has been a modular one so that the different modules can be readily adapted when creating a new experimental facility. The whole CORBA based architecture means that these modules can be mapped onto physical machines in a flexible fashion as dictated by other design constraints. Technical implementation and Systems Architecture of the TCD Experiment The systems architecture for the TCD computer vision experiment is shown in Figure 6. The equipment is controlled mostly via RS232 connections by various programs (C++, Java, and Java JMF) running on the lab server, all of which export a CORBA IDL interface. These interfaces are invoked remotely using CORBA by servlets running in the web server (Tomcat). The servlets themselves are activated by HTTP commands invoked from the client. A video-stream is maintained between the camera connected to the Lab Server and the web server. In order to reduce bandwidth requirements for the client, which must perform acceptably over a telephone modem, the video-stream is sub-sampled by an applet running on the client at about one frame per second. An added difficulty for this group of experiments is that the images provided to the client must be of sufficient quality for processing. Hence the reduced bandwidth to the client must not be at the expense of image quality. This architecture, featuring clean separation of lab server, web server and client allows us to make technical decisions within each machine with relatively little impact on other parts of the system. Thus for example, alternative lights and controllers had been used in an earlier version of the experiment with only some changes to the exported IDL interfaces. Furthermore, use of the HTTP only approach between client and web server allowed students to use the system from home via a telephone modem and ISP – there were no difficulties with firewalls that might arise if CORBA invocations were made directly from the client or if the video was streamed directly to the client. Mediating all equipment operations through the web server meant that it was a relatively straightforward matter to implement logging. Figure 6: Systems Architecture Schematic for TCD Computer Vision experiment Technical implementation and Systems Architecture of the Porto Experiment A full description of the remote electronics design and test facility developed at FEUP has been given elsewhere (Martins Ferreira, et. al. 2002); it is briefly outlined here together with some information on the experiments it is designed to support. A first set of experiments was developed to support the Design for Testability class offered to final year undergraduate and M.Sc. students in Electrical and Computer Engineering (ECE). The remote hardware for these experiments consists of demonstration boards containing one or more components compatible with the IEEE standards 1149.1 (standard test access port and boundary scan architecture) (Test Technology Standards Committee of the IEEE 1993) and 1149.4 (standard for a mixed-signal test bus) (Test Technology Standards Committee of the IEEE, 2000). XY Table Camera X.10 Lights Lab Server Web Server Client RTP/RTC P RS232 RS232 RS232 Servlet IIOP Servlet IIOP Servlet IIOP Applet HTTP Applet HTTP Applet HTTP