Combining virtual and remote interactive labs and visual/textual programming: the Furuta pendulum experience Daniel Galan, Luis de la Torre, Dictino Chaos, and Ernesto Aranda UNED, Madrid 28040, Spain, [dgalan, ldelatorre, dchaos]@dia.uned.es,
[email protected]
Abstract. This paper proposes a new way of experimenting with online (virtual or remote) interactive laboratories. Experimentation possibilities can be opened by allowing students to interact with the online laboratory using a visual and textual programming language that can communicate with the laboratory application and which includes tools to define and plot graphs. The combination of interactive laboratories with a visual and textual programming language, benefits both teachers and students: the former have a wider range of possibilities when considering the assignments that can be proposed and the latter acquire a greater knowledge of the plant under study by facing a more inquiry-based approach for online experimentation. To demonstrate the usefulness and possibilities of this environment, a Furuta pendulum system has been successfully used in both its remote and its virtual version. Keywords: virtual labs, remote labs, online experimentation
1
Introduction
Education in science, technology, engineering and mathematics (STEM) disciplines require practical experimentation. In traditional education, this experimentation has usually been performed in laboratories or the field. However, in online and blended education, computers constitute a very interesting tool for carrying out experiments. From the necessity of performing experiments under the online and blended education methodologies, simulations or virtual laboratories and remote laboratories were born. This type of laboratories is useful for the two previous educational scenarios because of their advantages over hands-on laboratories [2, 5, 7, 9, 11]. The vast majority of nowadays virtual and remote laboratories implementations are based on interactive experimentation [8]. In such labs, students change parameters in the lab graphical user interface and see the evolution of the system in real-time. However, even with its many benefits, interactive experimentation has some important drawbacks. Perhaps, the most relevant one is that students sometimes try to solve problems in a trial and error process [6]. Instead of reflecting in advance on what result they want to obtain from the experiment/system
and thinking on intelligent approaches for reaching it, they just manipulate the laboratory to see what happens, hoping that some combination of buttons and input parameters may result on a response that is close to the one they are looking for. Therefore, working with these labs does not necessarily require the knowledge of the underlying concepts. In contrast to this interactive experimentation, automated experiments do not have this lack. Students must think in advance how to face a problem and how to work with the lab in order to obtain the results they might be looking for. This paper presents a visual and textual programming experimentation environment that mixes interactivity and automated experiments. On the one hand, interactive experimentation allows students to modify parameters to see immediately reflected the output changes and the evolution of the model behavior in the graphical user interface. On the other hand, when some (textual or visual) programming needs to be done by the students, the experimentation process requires more involvement from them than just pressing buttons, entering values in input fields, moving sliders and/or watching at data being automatically plotted in predefined graphs. We believe that, in such scenario, students would not only be more motivated to work, but they will also: 1) be required to demonstrate more knowledge about how to solve the problem and 2) they will better develop their technical/scientific skills.
2
The visual/textual experimentation environment
We propose an experimentation environment (EE) that supports: (1) using existing laboratories without requiring any extra adaptation; (2) writing experiments for those labs in a visual programming language; (3) writing experiments in a textual programming language; (4) running the experiments with an interpreter (so that experiments are executed on the fly); and (5) collecting and plotting data from the experiments. The EE proposed in this work consists of three elements, which are clearly visible in Figure 1: (1) the experiment editor (marked with a red rectangle at the bottom), (2) the custom charts panel (blue box at the top right) and (3) the online laboratory (green box at the top left). Experiment Editor The experiment editor is the component in which the programming of the automated experiments is done. It is formed by a script area and a menu, located on the left, with the different categories in which the students can do the programming. The programs created here must be automatically interpreted. This way, students do not need to recompile the experiments over and over with every small change they make in their code. Instead, they can just run it, see if the results are what they expected and continue creating the experiment. Custom Charts Panel The EE proposed in this work allows the creation and customization of charts. Students first decide the data they want to visualize and
Fig. 1: General architecture of the experimentation environment
then, they can define the title, the sampling period and the maximum number of points they want to plot. Once defined, the charts are automatically created, and the information is shown in real time. It must be also possible to create different charts for the same experiment or to confront data from different experiment executions. Online Laboratory Laboratories are automatically prepared to be used in the environment with no extra adaptation or implementation. The type of the laboratory, whether virtual or remote, is entirely transparent for the EE and its use is not influenced by the nature of the laboratory at all.
3
Implementation
This section details how the implementation of the three components (the experiment editor, the custom charts and the online labs) of the visual/textual experimentation environment is addressed. 3.1
Blockly for the experiment editor
Blockly, an open-source project developed by Google, is a JavaScript library for visually programming code with blocks. The project started in 2011 and nowadays it is used in a large list of web applications. This project aims to teach basic
programming knowledge to new users by linking pieces of code like a jigsaw puzzle. The scripts created with Blockly can generate JavaScript, Python, Dart, and PHP. However, it can be customized with new blocks and with new functions to generate other computer languages [12]. In the presented EE, the generated language is JavaScript because it fits perfectly with the laboratories implementation. New blocks have been defined in Blockly to access the online lab variables and functions, allowing a complete control of the lab through programming. 3.2
Chart.js for the custom charts
Chart.js is an open-source JavaScript library that enables the creation of HTML5 charts. It is the library chosen by Moodle to create their charts, so it fits nice with the environment. It has several remarkable features: – It includes eight different types of charts that can be mixed, customized or even animated. – As it is built upon HTML5, it has a great performance in modern browsers, which is very important in real-time charts like the experimentation ones. – The charts have a responsive design so the experimentation environment can be used with computers, mobile phones or tablets. 3.3
EjsS for the online laboratories
Technological advances have implied that the software surrounding virtual and remote laboratories has got increasingly complex. Creating a graphical user interface to operate with the laboratory is not trivial, especially for those who do not have fluent programming skills. Fortunately, EjsS offers high-level graphical interfaces to create computer simulations. Users with little knowledge of computer programming can focus their effort on defining the mathematical model of the lab, and how the graphical user interface should look like. Any other aspect of the implementation is automatically generated. EjsS is part of the OSP, which provides free online resource collections through the ComPADRE digital library. Among these resources, users can find more than 500 applications created with EjsS: http://www.opensourcephysics.org. 3.4
UNILabs for deploying the EE
UNILabs (University Network of Interactive Labs) is a web 2.0 of interactive laboratories, a Learning Management System (LMS), where any university can freely deploy their laboratories and offer them to their students [10]. It was created in 2013, and nowadays it offers more than 20 remote and virtual laboratories distributed in 31 courses from a variety of specialties (automatic control, mathematics, optics, automation, linear systems, modern and classical physics, among others). UNILabs is based on Moodle, which offers excellent features to manage the experimentation resources by the teachers, and it includes the EJSApp Moodle plugins to deploy the EjsS laboratories. The UNILabs web page (http://unilabs.dia.uned.es) includes more information about the courses and universities that collaborate.
4
The Furuta Pendulum Online Laboratory
The virtual laboratory consists of a simulation of the pendulum equations (1) and (2) (where β is the angle described by the rotary arm, and α is the angle described by the pendulum.), developed in EjsS. The simulation incorporates a 3D representation and a few inputs to interact (see Figure 2. The user interface is as simple as possible, and allows only the most basic actions: change the position of the pendulum, the reference, and stop, pause or resume the simulation. h2 sin2 α + h1 h2 cos α sin αβ˙ 2 2 ˙2 α ¨ = h h cos α sin α β 2 3 β¨ = H H h2 sin2 α + h1 (−B1 α˙ + h5 sin α) h3 cos α (−B1 α˙ + h5 sin α) H H ˙ ˙ −h θ cos α B0 + 2h2 θ˙1 cos α sin α 3 0 −h4 β (B0 + 2h2 α˙ cos α sin α) H H −h4 −τ + h3 α˙ 2 sin α −h3 cos α −τ + h3 θ˙12 sin α H H (1) (2)
The remote laboratory has two main components: 1) the server side, developed in LabVIEW, that accepts connections using a component called JIL [3] and 2) the lab application in EjsS, whose variables are linked those LabVIEW. The remote lab interface is very similar to the virtual one, but it presents a webcam video streaming of the pendulum instead of the simulated 3D view.
Fig. 2: Virtual (left) and remote laboratory (right)
The virtual and remote laboratory user interface has been streamlined as much as possible without losing usability. This is the crucial difference with pre-
vious designs that are bloated, including lots of tools and visualizations focused on a specific task. As a comparison, Figure 3 shows an “old style” user interface for this laboratory. The old interface needed to anticipate to the users’ needs. Thus, it showed lots of elements for visualizing variables and several menus with related advanced options. One important feature of the laboratory is that it enables to change the controller of the plant. This has been done in previous laboratories as well, but using a specific language to the domain of application, which needs a special server for its execution (see [4] for a previous successful implementation of this idea). In this work, this task has been faced with a novel approach being the controller defined in JavaScript. Hence, the same code can interact without modification with the simulation on the browser and with the real system. In the later case, the JavaScript code is executed in a sandbox in LabVIEW. Furthermore, the controller needs not to be “written” at all, and the laboratory developed in EjsS does not have an editor or options to load and save files. Everything (from the controller to the visualization) can be constructed using the blocky language from the environment, as the next section illustrates. Thus, the user interface is general, simple and can be used for many different purposes and assignments without any modification.
Fig. 3: Old style laboratory with a complex graphical user interface
5
Illustrative Experiments Developed
This section presents some experiments students can perform using the Furuta pendulum remote laboratory. Thanks to the EE, students can not only carry out these technically complicated experiments in a simple and intuitive way, but as a flexible environment, they are encouraged to investigate and test their own controllers. In this way, teachers can use the environment as an additional tool for applying inquiry-based learning.
5.1
Keeping the pendulum upwards while the rotatory arm follows changes of the reference
In many control engineering remote laboratories, a typical approach is to implement the controller on the server side. That is, instead of having the controller implemented on the client side, sending periodically the control signal to the server, the code of the controller is sent once to the server, and it is executed there.
CLIENT SIDE
SERVER SIDE
Fig. 4: Client and server side of the experimental setup when the position controller experiment is executed
The visual experimentation environment discriminates, with no need for user intervention, between the code to be executed locally and the code to be executed remotely. Figure 4 shows an experiment with local and remote code to control the pendulum and to visualize the outputs. The plant has a default controller that puts the pendulum upwards and a student controller that can be replaced. Thus the first step is to disable the default controller and the second one to replace it with a linear feedback controller (showed in detail in Figure 5a). The code that replaces the controller’s function is the code that will be remotely executed (highlighted in red), while the rest is locally executed. Figure 4 presents a screenshot of the server computer. It shows the LabVIEW program that controls the input and outputs of the Furuta pendulum system. The remote code that is developed in the environment and sent automatically to the server is highlighted in red. These two elements are also illustrated more clearly in Figure 5: at the top, the controller designed with Blockly, at the bottom, the code that arrives at the server once the experiment has been executed. Once the controller code is received, the server runs that code in every execution step and sends the new control action value to the pendulum.
(b) Server side
(a) Client side
Fig. 5: Detailed view of the experiment code and the controller received in the server
The experiment designed with Blockly can be seen in Figure 5a. The “Create Chart” block, located at the top, is used to define the graph. It will draw the traces of the reference of the angle described by the rotary arm (“betaRef”) and its real measure (“beta”) in function of the time (“t”). Every 100 milliseconds, a measurement will be made. After this definition, there is another set of blocks in the experiment: the “start data collection” block initiates the data acquisition for the visualization; the “set” block modifies a flag to indicate to the server that a user-defined controller will be used; and finally, the “replace function” block is used to replace the controller function. The content of this block will be sent to the server and used as a controller in the remote lab. To do this, the blocks will be translated into JavaScript code and sent to the server once the experiment is run. At the top right part of Figure 4, the graph obtained after the execution of the experiment can be seen. Changes in the angle reference, made during the execution of the automatic experiment using the lab’s graphical user interface, are visible by looking at the steps in the graph. It was changed to 1.48 radians first, and then to -0,38 radians. Thanks to this experiment, it can be seen how the parameters set for the controller are appropriate, since, in addition to making the pendulum stay in equilibrium, the system is able to follow the benchmarks marked with efficiency. The IP camera, along with the graphs defined in the experimental environment, allows users to corroborate this fact. Also, it is effortless to test other parameters and see that, either they are not as effective as those used in the experiment, or they make the system unstable, and the pendulum falls.
5.2
Creating the base position controller with the swing up feature
Following the same process as in the previous experiment, it is possible to design a more complex controller. This controller is capable of not only to control the position of the base, but also to swing it up if the pendulum drops. This way, if the controller detects that the pendulum is far away from the region of attraction,
it will run the code that will push it up. Otherwise, it will execute the code seen in the previous experiment. For the implementation of this controller based on the design of ˚ Astr¨om [1], instead of using traditional blocks, a JavaScript code evaluation block has been used. Being a controller that requires more code for its implementation, the use of blocks can make the creation process difficult, so the experimental environment offers the additional possibility of writing code to advanced users. As the system raises the pendulum automatically, it is sufficient to, firstly, send a controller in which the control signal is always 0 (u = 0 ). This will drop the pendulum and allow the required controller to be checked.
Fig. 6: Swing up and position control experiment
Figure 6 illustrates the experiment created. It has the same structure as the previous experiment, but the controller has been defined in JavaScript. For this, instead of using the blocks to set variables and equations, an “evaluate” block is used. In this block, users can write JavaScript code (see the bottom part of the defined experiment). To check its performance, it is sufficient to observe through the IP camera how the pendulum is lifted when the experiment is run, and the controller begins to operate. Once lifted, the behavior is the same as in the previous experiment.
6
Conclusions
Most of nowadays virtual and remote laboratories are closed applications which offer experimentation tasks purely based on interactivity, which limits the students’ work with the labs. This paper presents an experimentation environment capable of overcoming these limitations. To this end, the environment adds new functionality to interactive laboratories, such as: 1) the possibility of designing automated experiments with a visual and easy-to-use language, solving the limitations of interactive experimentation; 2) the ability to add student-designed graphs to the visual interface of the environment, giving new possibilities for
visualizing results; and 3) the ability to redefine functions and modify variables the designer might not have considered interesting at the time, opening laboratories to new experimental tasks that were not previously possible. To show the experimental environment usefulness, two different experiments are presented for a Furuta pendulum remote laboratory.
Acknowledgment This work has been supported by the Spanish Ministry of Economy and Competitiveness under the project CICYT DPI2014-55932-C2-2-R.
References 1. ˚ Astr¨ om, K.J., Furuta, K.: Swinging up a pendulum by energy control. Automatica 36(2), 287–295 (2000) 2. Brinson, J.R.: Learning outcome achievement in non-traditional (virtual and remote) versus traditional (hands-on) laboratories: A review of the empirical research. Computers and Education 87, 218–237 (2015) 3. Chacon, J., Vargas, H., Farias, G., Sanchez, J., Dormido, S.: Ejs, jil server, and labview: An architecture for rapid development of remote labs. IEEE Transactions on Learning Technologies 8(4), 393–401 (2015) 4. Chaos, D., Chac´ on, J., Lopez-Orozco, J.A., Dormido, S.: Virtual and remote robotic laboratory using ejs, matlab and labview. Sensors 13(2), 2595–2612 (2013), http://www.mdpi.com/1424-8220/13/2/2595 5. Frerich, S., Kruse, D., Petermann, M., Kilzer, A.: Virtual labs and remote labs: Practical experience for everyone. In: Engineering Education 4.0. pp. 229–234. Springer (2016) 6. Guzman, J.L., Costa-Castello, R., Dormido, S., Berenguel, M.: An interactivitybased methodology to support control education: How to teach and learn using simple interactive tools [lecture notes]. IEEE Control Systems 36(1), 63–76 (2016) 7. Heradio, R., de la Torre, L., Dormido, S.: Virtual and remote labs in control education: A survey. Annual Reviews in Control 42(Supplement C), 1 – 10 (2016) 8. Heradio, R., de la Torre, L., Galan, D., Cabrerizo, F.J., Herrera-Viedma, E., Dormido, S.: Virtual and remote labs in education: A bibliometric analysis. Computers & Education 98, 14–38 (2016) 9. Potkonjak, V., Gardner, M., Callaghan, V., Mattila, P., Guetl, C., Petrovi´c, V.M., Jovanovi´c, K.: Virtual laboratories for education in science, technology, and engineering: A review. Computers & Education 95, 309–327 (2016) 10. S´ aenz, J., Chac´ on, J., De La Torre, L., Visioli, A., Dormido, S.: Open and low-cost virtual and remote labs on control engineering. IEEE Access 3, 805–814 (2015) 11. de la Torre, L., Sanchez, J.P., Dormido, S.: What remote labs can do for you. Physics Today 69, 48–53 (2016) 12. Trower, J., Gray, J.: Sigcse. In: Proceedings of the 46th ACM Technical Symposium on Computer Science Education. pp. 677–677. ACM (2015)
