Running Control Engineering Exp eriments Over the Internet y Carisa Bohus Burcin Aktan Molly H. Shor Lawrence A. Crowl Department of Computer Science Oregon State University Corvallis, Oregon 97331-3202 Technical Rep ort 95-60-07 August 1995 Abstract An imp ortant issue in engineering education is the availability of lab oratory resources for student use. Using a computer network to link geographically distant students with lab oratory teaching resources makes exp ensive and innovative equipmentavailable to more students. At Oregon State University,we provide a working environment where remotely-lo cated students can develop and run controllers on exp eriments in our control engineering lab oratory. Remote users can watch the exp eriment in real time from a remote workstation, hear the sounds in the lab oratory, and interact with other lab oratory users. Remote p ower control, network reliabili ty, and safety features are integrated into our exp erimental hardware and software design. Key Words: control engineering education, remote control, distance learning, Internet. This work was supp orted in part by Oregon Joint Graduate Scho ols of Engineering under NASA GrantNAGW- 3965 and in part by the National Science Foundation under Grant DUE-9352734 Department of Electrical and Computer Engineering y Department of Electrical and Computer Engineering, Phone: 503-737-3168, Fax: 503-737-1300, E-mail: [email protected] 1 Intro duction Practical exp erience is a very imp ortant part of control engineering education, but it is resource intensive. Innovative control exp eriments can take time, money, and energy to design and to construct, and are often not fully utilized throughout the academic year. Sharing exp eriments remotely enables greater use of unique lab oratory equipment, brings down the exp eriment cost p er student, and makes more exp eriments available. Our goal with the remote lab paradigm is to provide remote access as e ective as lo cal access. Control engineering instruction should combine theory and practice in each lesson. Students must b e able to mo del systems adequately in order to develop controllers that enforce certain p erformance requirements. After a controller is designed and simulated on the mo del, observing the dynamics of a physical implementation gives the studentvaluable insight. Data collection and visual feedback are imp ortant asp ects in control engineering instruction for the mo deling, system identi cation, and testing stages. In the past, students had to b e in the lab oratory to gain practical exp erience; now they can b e anywhere. Distance learning is an emerging new paradigm where students, teachers, and equipmentmay b e in geographically di erent lo cations. Second Best to Being There SBBT is a network appli- cation combining new and existing software and hardware to provide remote lab oratory users the opp ortunity to conduct live exp eriments o -site. For SBBT, the Internet provides the communi- cation infrastructure b etween students and the exp eriments see Figure 1. This may b e the rst time an undergraduate lab oratory has b een made fully accessible using computer networking to ols. In the next section we discuss related work. Section 3 details the remote lab paradigm, and describ es the trade-o s we made in our implementation. Section 4 provides an overview of the hardware. Finally,we conclude with the main lessons from taking our design to implementation. SBBT Client SBBT Client The Internet Cloud SBBT Server Controller Robot The Experiment SBBT Client OSU Campus Figure 1: Internetworking Context for the SBBT Application. SBBT is a client/server application that enables distantly lo cated students to control exp eriments on the Oregon State University campus. 2 Related Work Three distinct areas of research stand in contrast to SBBT. They are telerob otic systems, virtual reality or simulation systems, and large multi-lo cation pro cess control automations. SBBT do es 1 Figure 2: The Remote Lab User Interface for SBBT. This is the display the remote student will use to conduct exp eriments. Clo ckwise from the top left corner: 1 video window of the control exp eriment, a 3-DoF rob ot arm, 2 collab oration to ol showing a blo ck diagram and some discussion, 3 an Xterminal window representing the lo cal developmentenvironment, 4 the lab environment control window with the panic stop button and 5 the audio con guration window. not duplicate these imp ortant application areas; it gives students exp osure to equipment they lack at their own site. Telerob otics share some characteristics with SBBT; b oth op erate over long distances, and b oth work with moving systems. But, telerob otics, where remote movement is generated byintentional force by the op erator, is fundamentally di erent since it has an human op erator directing the remote actions. For example, Lee and Lee [7], describ e a real-time telerob otic system that was designed for use in outer space repair missions. The teleop erator uses force on a sensory device e.g., a mouse or joystick to direct the actions of a rob ot arm at the remote station. Another example of telerob otic systems are available on the World-Wide Web. These applications enable the distant user to move rob ot arms which tend a garden [11], or move blo cks on a table [12, 10]. Again, the user clicks on a schematic, or still picture to move the rob ots, thus directing the action. In contrast to telerob otic systems, our system provides an environment for exp erimentation with 2 control co de, whichisdownloaded to the equipment and then run on the equipment itself. That is, instead of transmitting control signals, the remote student transmits control programs which are run, enabling the equipment to handle tasks autonomously. Rob otic systems are b eing develop ed to accomplish increasingly complex tasks. Appropriate training on complicated equipment is critical. Miner and Stans eld [9], describ e a metho d to ful ll these training requirements. They designed a virtual reality rob otic control system to train op erators more eciently in real-time op eration. Virtual reality can b e thoughtofasaninteractive user interface to a simulation system. Simulation provides a cost-e ectiveway to learn systems that are exp ensive or p otentially dangerous to sta with inexp erienced p ersonnel. However, simulation means working in a closed universe, which omits some physical realities. There will always b e an imp ortant place for simulation systems, but they cannot completely substitute for exp erience with actual systems. Researchers [3, 6], from ve institutions have develop ed a factory automation testb ed for dis- tributed telerob otics research. The ve sites, which are connected by the Internet, provide an exp erimental environment for standardizing device interfaces, testing proto cols, distributing tasks, developing user interfaces, and supp orting collab orations. SBBT, in contrast, is designed to provide a more intimate setting, where one student can design and carry out an exp erimententirely on his or her own. The emphasis in our design is to fo cus the remote user's attention on the exp eriment, not on the system that supp orts the exp eriment. Several distance learning pro jects-in-pro cess are noted in app endix A. 3 Paradigm and Application Imagine a control engineering student, developing a controller for a 3-DoF Degree of Freedom rob ot arm. Her scho ol do esn't have a rob ot arm, but a university 85 miles away do es. She sits in front of a computer screen and downloads her co de to the distant university rob ot arm exp eriment over the network. As so on as the control co de is compiled, linked and loaded, she can watch her co de run on the rob ot, in real-time. She observes that the controller p erformance do es not meet her design goals, mo di es her controller co de and runs it again, rep eating this until she is satis ed. She is working in a remote lab oratory using a new paradigm. The remote lab paradigm is based on a software user interface and a hardware con guration. In this section, we describ e our approach and implementation of the user interface; the hardware con guration is discussed in Section 4. There are ve main functional parts components to the user interface: 1 the exp eriment, 2 lab environment control, 3 lab presence, 4 collab ora- tion, and 5 safety.We develop ed an op en architecture for the overall system, with a varietyof implementation choices for each comp onent, balancing costs and functionality needs. 3.1 The Control Engineering Exp eriment This comp onent is basically unchanged from what it would b e conventionally. Common exp eriments in our lab are x-y p ositioning tables, rob ot arms, DC motor control, and magnetic susp ension systems. Criteria to consider when selecting an exp eriment for remote use fall into three categories: economics, logistics, and app earance. 3 If substantial time, human, or nancial resources have b een dedicated to design and build an exp eriment, it is a worthy candidate to makeavailable to remote students. The cost of simply replicating an exp eriment should b e compared to the e ort and exp ense of installing SBBT, keeping in mind that most SBBT costs o ccur only once, while replication costs scale. If replicas cost more than SBBT, it makes sense to use SBBT. The logistic considerations, which can b e automatic or manual, are 1 remote p ower control, 2 safety for p eople and prop erty in the lab, 3 ability to run without human intervention, 4 1 a stable start p osition, 5 at least one reset p osition, and 6 the abilitytodownload control co de.