I first encountered the concept of remote labs, or remotely accessible laboratory hardware, twelve years ago. Since then, the state of the art in telepresence and communications systems has progressed in leaps and bounds, but, somehow, remotely accessible engineering labs remain an unsolved problem. That’s not to say there aren’t solutions to the challenge of connecting to remote hardware. There are dozens of ways that institutions have addressed the problem. In other words, no disruptive technology or obvious solution has emerged to completely solve the problem, eliminating the need for academics to roll their own platform.
For those considering creating a remote lab to give students the ability to have hardware experiences from home or after hours, here are some of the challenges and considerations you may face, and some recommendations.
How Responsive is the Experience?
One of the first questions you’ll need to answer is how often students will need to send commands to the remote system and receive a response back? The answer to this question will inform a variety of elements of your design, from the communications protocol that you choose to the type of hardware and software platform that manages access to the system. For example, if you’re building a system for teaching control systems, you could transmit a package of command(s) and control parameter(s) to the remote system with an intended test duration, and then analyze the results of the test when it completes. That could be accomplished using a completely asynchronous system like a REST API, eliminating the need for real-time synchronized data flow between the user and the control system. On the other hand, if you foresee students needing to make repetitive changes to the parameters of the system, a more responsive approach such as TCP/IP or an IoT protocol such as MQTT could be considered. That would give you a much more responsive system, but unless your connection is optimized and persistent, it could serve to highlight any issues with remote access and distract students from the overall experience.
I would personally recommend a blended approach that combines an asynchronous stream for occasional updates to parameters with a higher-speed “real-time” connection to stream data back from the plant. That should give students an experience that is as close as possible to using the plant directly, without putting too much load on the bandwidth to the remote system. Ultimately, for this and most other decisions that come out of the process of creating a remote lab, the most important is to consider the student experience and build around the closest possible analog to in-person operation.
How Immersive is the Experience?
Once you have an idea of how you would like students to communicate with the remote system, the next question is how much of the environment is important for them to experience as they’re operating the hardware? Options start on the completely isolated end of the spectrum, with an experience where students only interact with the parameters and data itself without any knowledge of the state or context of the remote system. Adding a real-time video feed might make that experience a little more intuitive, without introducing too much complexity. From there, you might introduce a virtual “digital twin” that represents the state of the system in a virtual environment to give an accurate view of the machine. On the more realistic end, you could include not only video but multiple video feeds, audio, or even telepresence into the mix to try to immerse students into the real environment. Finally, the advent of AR and VR has created the potential to either replicate the remote plant completely in the local environment or, alternatively, to enter a completely virtual environment.
My recommendation here would be to split the difference between isolating students from the remote hardware, and the logistics and complexity of a completely realistic experience. Typically, I combine the parametric view with as many camera feeds as possible so that students can monitor both the data and the actual remote plant. Without cameras, I worry that students might think that they’re interacting with a simulation, and, to be honest, they almost might as well be.
Where is the Experience?
Both locally, at the hardware location, and remotely, where students access your system, it’s important to decide what type of interface will be used. Locally, will the hardware be stored in a closet or rack, or will it be out in the open and usable by local students as well? Will the computational equipment driving the system be PCs or embedded systems, and how will they respond to power failures or other interruptions? What will the network topology of the system be, and will there be considerations for security and system safety? On the remote user end, will students access the system using a mobile app, website, or local app on their computer? Will they be expected to create software to run the hardware remotely, or simply change the parameters of existing algorithms? Again, the most essential thing is to work out the most consistent and reliable workflow for the users, while ensuring that the hardware is safe and secure.
On the local side, I would recommend using either individual embedded computers such as Raspberry Pis, or a single centralized PC to run the hardware, depending on the types and configurations of experimental platforms you’re using. Either way, systems should always use wired network connections where possible and live on an isolated VLAN from the rest of the network they share. Access to the systems should be granted using either a password, token, or booking system that allows users to use the system only during specified times and limits the access of third parties. A “man-in-the-middle” management system might be a great way to ensure that only authorized traffic reaches the final destination at the hardware plant.
On the user side, depending on the circumstances, each access method has its advantages and disadvantages. I’ve used local applications, mobile apps, and websites, and I’ve had good and bad experiences with all of them. If the system is implemented in a robust and reliable way for the most common use cases, then it should be a great experience all around.
Quanser Remote Hardware Experience
We at Quanser have been creating our own tools for remote access labs for well over ten years. We have a lot of ideas on how to make remote access easier, more reliable, and, ultimately, a better learning experience for students. For example, our Experience Controls mobile textbook includes the Remote Hardware Experience that gives you a chance to change the control parameters on a servo motor located in our office 24h a day:
In terms of a more comprehensive platform, we have yet to create a unified solution that would bring together the advantages of our technology stack. But we’re on it 😉 Stay tuned for updates as we work to make the future of remote access a “reality.”
