Jacques Fayolle is co-director of the French Télécom Saint-Etienne Engineering School in Information Technologies where he is responsible for driving local research activities on interoperability for Information Systems. In this article, Jacques talks about the concept of a “remote lab” where users can access the lab via an Open Wonderland collaboration space.
The Concept of the Remote Laboratory
By Jacques Fayolle
In this tough economic climate where limited resources are an obstacle to securing necessary laboratory equipment, there are unique opportunities. In the area of lab research, for example, different phases of work such as “production” and “monitoring” may not always be co-located. That is to say, highly technological and pricey instruments are not always controlled in situ (may not be in the same place or locale as the operator). There are, moreover, many companies that cannot afford to own all the instruments they need to carry out their work successfully.
Out of necessity, companies have begun to pool their resources and form groups of economic interest, often known as the “Extended Enterprise,” that collectively leverage and enable the purchase of expensive devices. In research and development, companies often need quick access to a given resource, but may only need that resource for a limited time, which does not justify the investment to purchase the equipment. By gaining access to equipment through groups of economic interest, firms can conduct work that would otherwise be out of reach economically. This scenario is particularly relevant in the learning field where devices used in production and are often re-used or re-purposed for learning. This is most likely done for economic reasons because it, in effect, doubles each investment.
Other benefits of remote labs, similar to Cloud Computing, relate to the training of workers and administrators. Instead of having to train workers on new equipment, it is possible to bypass the cost and time by relying on a group of “learners” who are already trained on the equipment and are able to operate it remotely.
In the end, all these situations lead to the need to control real devices remotely. Technology enabling organizations to remotely control laboratory equipment is what we refer to as the “remote lab.” It is important to distinguish between the remote lab versus the virtual lab. In a remote lab, we take active control of external devices via an Internet connection, whereas in a virtual lab, users mainly control software (sometimes very complex) that simulates the behavior of real devices. Obviously, reality uncovers unexpected situations. That is why we strongly argue that remote labs are better in comparison to virtual labs, especially for teaching and training. One of the key advantages of using remote labs as opposed to on-campus or local labs is that the physical constraints vanish. The user does not have to be physically present in the lab to carry out the experiments. As MIT Professor Jesus del Alamo said in 2005, “if you can’t come to the lab, the lab will come to you.”
One of the biggest challenges is how to generate the remote lab platform. We do not want to re-engineer software for every device or for each device class. Take a trivial example of the development of a single graphical user interface (GUI) allowing all devices, both electronic (operated primarily by buttons) and mechanical (mainly equipment that moves) to be presented graphically. Currently, this cannot be achieved without significant ”special case” or customization work in software integration and development. To reach this goal in a more practical manner, we propose a semantic web approach and to describe the remote GUI as a semantic file. More details on our proposal can be found in our “Nuggets of Research” document (PDF, in French) and in this IEEE Intelligent Systems article on the use of semantic tools for remote labs and how they improve the quality of learning.
Basically, in the proposed scheme, a Web Ontology Language file is used to describe the GUI (location, size, skill level of each widget) and the functionalities of each external device. The global architecture relies on a J2EE architecture. An Enterprise Java Bean loads and interprets the semantic description. Commands and results are broadcast to each participant through message-oriented middleware. The client is a standalone application which is deployed on the client side through Java Web Start technology. On the server side, we use software from the OW2 consortium including a Jonas J2EE server and JORAM Message Middleware.
Considerations for Implementing a Remote Lab in a Virtual World Environment
Another big challenge we face is collaboration inside the remote lab. Indeed, according to constructivism theory, it has been shown that the quality of learning is strongly dependent on the sharing of skills between and among participants. One of the main drawbacks of the remote lab is isolation of the remote user (a caricatured geek, alone in front of his computer ;) ). Therefore, the question to address is how will the remote lab platform support collaborative work?
Our first idea was to revisit the semantic web approach to describe the collaboration policy on the remote lab platform. To do that, we used the Semantic Web Rule Language. This tool allows us to represent a typical collaboration situation. We identify who is the actor, and who are the spectators. We further identify who is requesting to become the actor (we assume that there is only one actor in the remote lab at a time). We describe the collaboration policy, for example as, “User in late has the higher priority to access the lab, however, teacher or superuser still gains preemptive access.”
Let’s look at the following scenario to gain a better understanding. Suppose that Dave (the professor) and Alice (his student) have to conduct a practical session on device 1, whereas Bob (another student) has to work on device 2.
Dave, Alice and Bob launch the remote lab software (for example, an instance of an OCELOT client using Java Web Start) on their own computers, which then loads the semantic file corresponding to the device they wish to use. Group awareness/interaction between Dave and Alice is facilitated by the JORAM messaging service which relays the commands made by Dave to Alice’s screen, for example by displaying the button pushed by Dave in a specific color. It is very difficult, however, for Dave to know what Alice is doing (reading the course lesson, reading the practical session subject, or watching him doing a demonstration). The user-induced messages are summed up by the black arrows in the above scheme.
By integrating and using the device control software in a virtual world such as Open Wonderland, collaboration between Dave and Alice is manifested by avatar actions and interaction. Now, when carrying out the actions described above, Dave can clearly see the level of Alice’s engagement in the process (is she watching the remote device on the screen or reading the practical session subject exposed as a PDF on a virtual wall, for example). The inspiration for this idea came from reading the WonderBlog article, Reviewing Wonderland Code In-World.
Another advantage of collaborative working in the virtual world in this context is that Dave and Alice are now working on the same instance of the OCELOT remote client. This reduces the number of client launches, simplifies communication requirements between multiple instances of the client, and removes competitive/conflicting commands sent to the remote hardware.
Two major considerations emerging related to making remote laboratories more effective in virtual worlds are:
- Effective collaboration and communication between learners; and
- Remote laboratory realism, i.e. physical representation of the real laboratory (“reality awareness”).
In terms of realism, our goal is for the remote user interface of the laboratory equipment be as close as possible to the physical interface. A user who has invested time to learn to operate equipment in the virtual world should be able to reap the benefits of this training when the time comes to use the same physical device (or vice-versa). The use of a virtual world helps us reach this goal since it allows 3D representation of objects and, therefore, realistic renderings of the physical devices. It is particularly interesting for a remote robotics lab in robotics.
Proposal to Use Remote Lab in Open Wonderland
Apart from needing a dedicated server to run/host Wonderland, there is no substantial additional cost incurred for integrating laboratory hardware into Wonderland. Given that all the laboratory control tools are based on Java, and Wonderland worlds already have the ability to share Java applications through the X11 application-sharing mechanism, the different pieces of the puzzle are in place and technically feasible. The only item left to do is to declare the remote lab client software as a shared X11 app. Below is a screenshot of an avatar using such a client in Wonderland. The main additional overhead is network bandwidth. The bandwidth requirements for the use of avatars and audio communication adds some complexity in terms of interactions/data transfers and increases network traffic.
Use of a Network Analyzer in the “Remote Lab”” using OCELOT framework in Wonderland.
– Jacques Fayolle