Proceedings of the 10th Mediterranean Conference on Control and Automation - MED2002 Lisbon, Portugal, July 9-12, 2002. A REMOTE EXPERIMENT ON MOTOR CONTROL OF MOBILE ROBOTS A. Khamis*, M. Pérez Vernet, K. Schilling University of Applied Sciences FH Ravensburg-Weingarten Postfach 1261, D-88250 Weingarten, Germany. Tel.: +49 (0)751 501 9739, Fax: +49 (0)751 48523 *guest researcher from : Carlos III University of Madrid Avda. de la Universidad, 30, 28911 Leganés, Madrid, Spain. Tel.: +34 91 624 99 70, Fax: +34 91 624 94 30 e-mail: akhamis@ing.uc3m.es, perez@fh-weingarten.de, schi@ars.fh-weingarten.de Keywords: Mobile robots, telematics, virtual laboratories, virtual reality. Abstract Laboratory experiments are essential in engineering education, current telematics techniques allow now to offer such experiments with real hardware now also via Internet. Here a survey on the design and implementation of such remote experiments are addressed. Particular emphasis is on user interface enhancement through the use of virtual reality, as well as on network performance tests. 1 Introduction Virtual Laboratories represent a coordinated set of experiments for students with hardware facilities physically spread over different locations, but accessible by students via the Internet. Of special interest are the virtual laboratory experiments based on mobile robots, as they represent real complex systems integrating a broad diversity of concepts [9]. In the designing of these virtual laboratories for robotic systems a number of challenges must be addressed, particularly the telematics infrastructure giving access to the experiments [2, 4, 9, 11, 1, 7], as well as the user interface providing the necessary interactivity with the remote hardware supporting the learning process of students through appropriate feedback [3, 8]. At the ARS Laboratory (Autonomous Robotics Systems) in the University of Applied Sciences FH Ravensburg-Weingarten a virtual laboratory system has been implemented which has solved the communication problem successfully, offering a system which encapsulates the network transfer of data, enabling the future extension of the system by only developing new robot interfaces all of which can use the same communication core. The experiments offered by this virtual laboratory system are integrated in an international cooperation effort in which 14 partner universities in North America and Europe are involved. This paper offers a brief overview of the system and addresses its enhancement through the use of virtual reality. In chapter 2 the remote experiments conducted and the remote robot involved in those experiments are described, in chapter 3 the different modules in the logical architecture of the virtual laboratory system are presented, in chapter 4 the student user interface improvements through the use of virtual reality mechanisms are addressed, and in chapter 5 the tests and results of the network performance survey affecting the use of the virtual laboratory are summarized. 2 Remote Mobile Robots Experiments 2.1 The Experiments The educational objectives pursued in the virtual laboratory system described in this paper, with
the particular use of the TOM mobile robot, consist in enabling students geographically distributed to perform experiments on motor control, as support of given lectures. Through the performance of these experiments students consolidate the necessary knowledge to successfully teleoperate the remote hardware, achieving a better understanding of the functioning principles involved. Specifically, students have access to the following experiments: (i) Teleoperated Machine Fundamentals are introduced to the students through the use of step by step learning with interactive questions for learner feedback, helping the students to understand concepts from mechanics, kinematics, dynamics, sensors, control, robotics, etc. (ii) Identification of input-voltage to speed ratio aims to provide a fundamental study of the effect that this relation exerts over the mobile robot motor performance. (iii) Control of remote mobile robots demonstrates how a PI controller works, and the need of such controller. Wheel encoders (Hall sensors and magnets) are used for getting feed back for the PI controller. The user can study the effects of controller parameters on the motor performance. 2.2 The Mobile Robot Hardware At the University of Applied Sciences FH Ravensburg-Weingarten various teleoperated robots have been designed and integrated, for industry, space exploration and education [10]. The robot TOM (TeleOperated Machine), shown in Fig.1, is a small mobile robot with a chassis built from fischertechnik parts, equipped with a 16-bit Siemens 80C167 microcontroller, see Table 1, precision motors, and sensors. For the motor control experiments, only encoders integrated into the motor shaft are used. The communication between the server and the robot is accomplished over a serial cable. Fig. 1 TOM TeleOperated Machine Feature Timers PWM Units Primary Serial Port Secondary Serial Port Basic I/O Lines Description Used to control the time during which the motors move, so that they only work for the amount of time specified by the user at the Java client over the Internet. Used to generate the Pulse Width Modulation waves to control de motor s speed, and eventually the power of the motors. Used to connect the robot to the PC s serial port that holds the application server. Used to connect the LCD display. Used to control the sense of movement (forward-backwards) of the wheel s motors. Table 1: Microcontroller features used in TOM. TOM is always waiting to receive a new set of commands through the primary serial port, upon which the specified task is performed. If a set of commands is sent while performing a task, this set will be ignored because TOM only checks for new commands after completing the present task. 3 Internet-based Experiments Access Students will communicate and teleoperate the experiments using a web browser [9,11]. The task is executed by a local control system and the results displayed on the operator s browser. The following subsections discuss the main two tiers,
and the software architecture of the system as shown in Fig.2. Fig. 2 Remote Laboratory Architecture 3.1 The Client Tier This client-level interface includes position and speed control by adjusting the left and right wheels voltages, as well as the movement duration. Also the client can study the effect of the PI controller parameters on the robot. Round robin approach has been implemented to manage the user access. When only a single user is connected, no restrictions on usage are given. However, if multiple users are simultaneously connected, only one is given access for a specified amount of time. Once the time has expired, the next user in line will be given opportunity to control the robot and the first user will be moved to the end of the waiting list. A chat room is provided as a communication mechanism between the different users. Also a web cam with a streaming server provides a real time view of the robot movements. These interfaces are displayed in Fig. 3. 3.2 Tier In this tier, the following servers are installed, as shown in Table 2. Robot Backup HTML/Chat Backup A Solaris machine containing the robot s standby server. When the main server (the robot s server by default) turns inoperable due to equipment failure, or hacker attacks, it will be replaced by this standby server, reinforcing the system continuous availability. In parallel the main server will be fixed as soon as possible to be placed back as the default server. A Solaris machine containing the HTML-chat standby servers. As in the case of the Robot Backup, it will take charge in case of availability problems with the main server. The physical separation between the different standby servers provides robustness, and makes it less feasible that the whole system will succumb under hacker attacks, making recovery easier and faster. Streaming The streaming server transforms traditional analogue video into high quality digital images that can be transmitted over intranet networks or the Internet. The user streaming server is a standalone device not PC based which provides real time image transmission up to 25 frame/sec. Table 2: Virtual Laboratories s 3.3 Software Architecture The software architecture of the remote laboratory is based on a client/server model written mainly in Java [7]. 3.3.1 Client The Client class is a Java Applet that provides a basic operating environment and status information for the user application. A description of the modules composing the client side follows: System Main Description A Linux machine containing the robot s server, the chat server and the HTML content. (i) Client Negotiator: This module is developed to handle all network communications and user management. It reduces the complexity of the rest of the system since all network and multiple user
implementation details are securely encapsulated. Events are implemented in the negotiator module by creating multiple threads to continuously monitor the status of the system. (ii) User Management: Only one user at a time may control the robot. Each user is given a specified amount of time, after which the next user will get the opportunity in a round robin fashion. (iii) User Interface: When a robot is connected to the server, its identity is determined and the server dynamically loads up the appropriate module to correctly interface with the robot. implemented in the class. At a regular, specified interval, the server sends a specific byte array to query the robot. All robots at the university are required to be able to recognize this reserved format and reply with an appropriate format describing the robot. If a response is not received within a specified amount of time, it is assumed no robot is connected. 4 Virtual Reality Experiments support Through the use of a virtual reality user interface the student tele-operator can achieve a global view of the experiment state, in a fast and efficient way. Virtual Reality offers the capability of displaying a great amount of information to the user which is organized in a way that is meaningful at first sight, and which is not overwhelming, giving the tele-operator the opportunity to take decisions right away, as well as to shorten dramatically the time needed to extract results and conclusions from given experiments [8, 10]. 4.1 Virtual Reality Experiment Environment 3.3.2 Fig. 3 User Interface The class has built-in support for the serial device and provides a clean send/receive eventbased interface. It also implements a ping protocol to identify which robot is currently connected. A description of the modules composing the server side follows: (i) Negotiator: This module resides in the server to handle the communication and robot identification issues. It maintains separate threads for each connected client, all of which are always aware of their connection state. (ii) Robot Indentification: In order to automatically determine which robot is connected (if any), a ping/response protocol was With Virtual Reality the User Interface of Fig. 3 will be augmented with another window which shows the virtual simulation of the actual experiment, with the option of superimposition of both virtual and real camera images, a technique known as Augmented Reality and which serves to show the differences between real and simulated events. This virtual reality interface will be integrated to the already existing user interface, thus every different robot will has its appropriate virtual interface which will be automatically loaded in the virtual laboratory system as the robot in use is identified. Fig. 4 shows the VRML model of TOM which will be used in the robot s virtual reality interface, the virtual model is reproduction of the real hardware in 1:1 scale, also it can be seen the virtual environment where the experiments take place, and which reproduces the real environment.
hardware simulations permit students to perform experiments even though they have not gained the control over the hardware. This last is an issue of interest due to the limitation of Round Robin (RR) queuing control mechanism as the number of users grow, specifically: T is a design RR parameter which defines the maximum time an user should wait to regain control, as the number of users N grows, the amount of time each user can maintain control decreases proportionally (T/N), therefore a limitation in the values of T and N are imposed. 4.3 Virtual Reality use of Sensor Data Fig. 4 Virtual Experiment Interface 4.2 Virtual Reality Interface Features In the virtual environment students will be able to choose between a series of features during the experiments performance, which will help them in the learning and results achievement process. For instance, just to name a few, the students will be able to: (i) Change dynamically the viewport layout, that means different views (up to 4 in the same window: user-defined axonometric, top, front, right) are available, that makes it easier to follow robots movement, necessary to evaluate motor performance with value change in voltagevelocity radio, or PI control parameters. (ii) Intelligent cursor measuring capabilities, by clicking in the virtual environment the points of interest in the robots trajectory, as well as, automatic robot movement measurements, which will pop up in related windows as required by the students. This will enable students easier and faster performance of experiments aimed to study dynamics and kinematics models. (iii) Simulated robot performance detached from real operation, in order to assure correct post-realteleoperation. This is interesting in path planning, tracking and obstacle avoidance studies, for several reasons: to gain time by scheduling only those manoeuvres that actually lead to desired results. And in general, because detached from In the user interface of Fig. 3 the measurements to determine robots movement were performed by students as follows: On the web browser students have an actual image of the robot in its environment, which is refreshed at a sufficient refresh rate. They are enabled to freeze an image after a manoeuvre was completed in order to make some measurements for the determination of the position of the robot. This measurement is done through the use of the Pan/Tilt/Zoom Controls shown in Fig. 3 with the help of the grid on the floor, and the two light bulbs at the top of TOM. This mechanism tends to be quite inaccurate due to camera image deformation, and 3D to 2D projection deformation. Virtual reality applications can fight back this problem by the use of exact modelling of both robot and environment, and the use of different sensor data fusion mechanisms from which position and orientation measurements can be inferred. This data can be used to animate the virtual model of the robot, and as output of required measurements. 5 Network Performance The limited bandwidth and the random time delay are considered two main challenges to the remote laboratories [1]. A survey was conducted during the period from 7/1/02 to 5/2/02 to evaluate the network performance by measuring it between the University of Applied Sciences FH Ravensburg- Weingarten in Germany, and the University Carlos III in Madrid, which are partners in a
broader international cooperation effort in the framework of remote laboratories in the field of mechatronics and telematics [5]. There are special tools to measure the network performance like ttcp [12] or netperf [6]. In the ARS Laboratory the Netperf tool was used, which consists of two different executables: the netperf client in a 200MHz. Linux Machine at the University of Applied Science, and the netperf server a 300MHz. PIII Linux Machine in the Carlos III University of Madrid. A brief description of the conducted tests and the obtained results follows: 5.1 TCP Stream Test Here one way communication is tested, the client sends messages to the server which receives them. The throughput or bandwidth is calculated in both sides by using the message size, number of messages and elapsed time. Table 3 shows the results obtained. As it can be seen the throughput measured for the local host, i.e. the bandwidth within the intranet hosting the client, is much higher than that provided by the whole network between the client and the server, this shows that the internet outside the intranets imposes serious bandwidth limitations which has to be taken into account when developing a virtual laboratory system like the one addressed in this paper. Local Remote Max. Throughput (Mbps) Average Throughput (Mbps) Min. Throughput (Mbps) 204.4 180.44 97.08 4.1222 1.7126 0 Table 3: TCP Stream Test 5.2 TCP Request/Response Test Here bi-directional client-server communication is tested. The default send and receive packet sizes are the system socket buffer sizes. Table 4 shows the results obtained. The test was re-run several times using different test durations, and it was obtained that the transaction rate (transmission rate at the default packet size) is almost stable and doesn t depend on the test duration. Local Remote Max. Average Min. Trans. Rate 6455 5856.8 3630.93 15.943 7.1142 0 Table 4: TCP RR Test 5.3 TCP Connect/Request/Response Test This test mimics the http protocol used by most web browsers. Instead of simply measuring the performance of request/response in the same connection, it establishes a new connection for each request/response pair. Table 5 shows a comparison between the local and remote host transaction rates. Local Remote Max. Average Min. Trans. Rate 1447.576 1305.743 754.612 5.508 1.826 0 Table 5: TCP CRR Test 5.4 Network Performance Conclusions Network performance must frequently be assessed using empirical methods that combine performance testing and modelling. Bandwidth estimation measurements are of concern where accuracy is difficult to achieve, particularly in high-speed networks. The average throughput and transmission rate are almost stable and don't depend on the test duration. The results show that: (i) Connect/Request/Response protocols impose the highest data rate limitations due to the network latency, i.e. the time needed to access the network, nevertheless the experimentation shows that, even at this limitation margins, the rate is high enough to guarantee the feasibility of deploying such Internet-based remote laboratories using ordinary PCs, although time delays will be noticed by the students-users.
(ii) The limitation in bandwidth limits the refreshing rate of the video images, which prohibits experiments in which the scene might vary at high speeds, otherwise abrupt breaks and jumps in the visualization of the events will occur. Virtual reality images of a rendered simulation have much more lower needs in throughput, therefore they pose a better alternative to real camera images in these kind of situations. 6 Conclusions Virtual laboratories offer students access to complementary experiments, not available at the own university, as support to lectures. Thus they can experiment with remote hardware at a time schedule that they can select according to their needs. The implementation of the virtual laboratory system should make an efficient use of the resources to account for bandwidth and time delay restrictions. On the other hand, such systems should be implemented in an extendable way, which guarantees that the different software modules should not be rewritten when new hardware is installed to be accessed through the experiments. Virtual reality applications enhance the features of virtual laboratory interfaces, providing results in a more intuitive fashion, enabling students to speed up the learning process, also virtual reality permits to cope with data transfer restrictions in cases where life camera images are too demanding. Acknowledgements The authors are particularly thankful for the support obtained from the Project IQN - International Quality Network in Mechatronics and Telematics granted by the German Academic Exchange Service DAAD, and the Project IECAT within the EU/US cooperation program in Higher Education and Training. References [1] P. Backes, K. Tso, J. Norris, G. Tharp, R. Bonitz, K. All. Internet-based Operations for the Mars Polar Lander Mission, Proceedings of the 2000 IEEE International Conference on Robotics & Automation, pp. 2025-2032, (2000). [2] S. Dormido Proceedings of the IFAC Workshop on Internet Based Control Education, pp. 97-102, Madrid, (2001). [3] K. Forinash, R. Wisman. The Viability of Distance Education Science Laboratories, T.H.E. Journal 29 (2001), No.2 September, (2001). [4] K. Goldberg and R. Siegwart. Beyond Webcams: An Introduction to online Robots, MIT Press, 2002. [5] Innovative Educational Concepts for Autonomous and Teleoperated System (IECAT) http://www.ars.fh-weingarten.de/iecat/index.html [6] netperf http://www.netperf.org/netperf/netperfpage.html [7] J. Ogenss, K. Schilling, H. Roth. A System to Facilitate Telematic Implementation, 1 st IFAC Conference on Telematics Applications in Automation and Robotics, TA2001, July 24-26, Weingarten, Germany, pp. 117-122, (2001). [8] M. Pérez Vernet, K. Schilling. Virtual Reality for Tele-Education Experiment with Remote Mobile Hardware, Proceedings of the IFAC Workshop on Internet Based Control Education, pp. 97-102, Madrid, (2001). [9] K. Schilling, H. Roth, R. Lieb. Remote Control of a Mars-Rover via the internet to Support Education in Control and Teleoperations IAF-97-Q.3.05 Turin 1997. [10] Schilling, K. and H. Roth (1999). Mobile Robots for Education in Telematics, Control and Mechatronics, Proceedings of 14th IFAC World Congress, Volume M, p. 211-215. Beijing. [11] K. Taylor, B. Dalton. Issues in internet telerobotics. FSR 97 International Conference on Field and Service Robotics, (1997). [12] ttcp http://ftp.arl.mil/~mike/ttcp.html