Next-generation enclosures for use in public spaces
We’re expanding the provision of remote laboratory experiments on the city-centre campus at the University of Edinburgh. Space is quite tight, and we want to support a 10x increase in experiential learning hours for students. This is possible without building new buildings only because remote laboratories are 100x more efficient in their usage of space compared to traditional laboratories [stack 4-5x higher, open 3x longer, use >7x less space because there is no desk, chair or standing room required]. This is an attractive proposition about which we’ve previously published.
We want to do even better than that, and use otherwise unused space to host the experiments. That way, we avoid having to reduce space available for other teaching, and research activities. Public spaces such as foyers must be safe to exit during a fire, so we switched over to using metal boxes. The fronts are fire-rated PETG, and the boxes are sealed to keep in any fumes that would be released if there was a short circuit (we don’t expect any).
Our first installation in wooden boxes above provided over 2,500 hours of assessed coursework to 250 students in 2021, which we reported here. We’re delighted that the upgraded motors in this version of the experiment have worked even better, and that the containers have been a talking point for people passing by the foyer that they live in.
Andrew Brown designed this new container, and construction has been undertaken with his team including Calum Melrose. We’ve had a bunch of input from other team members as well (long list – you have our thanks even if not mentioned here!), such as Doug Halley keeping us on track with lighting and power, and we’re grateful to our fire, estates, and buildings teams for their advice and support. Over Summer 2022, Jonny Welsh and Zsolt Csonka – our interns – are producing around 30 more containers together with Andrew, Calum, using new smart power boards designed by Imogen Heard. We’re upgrading our wooden box internals too – with interns Bhavith Manapoty and Eralp Calhan. We’re pretty excited about what the new boxes will do – the reveal will come later on in the year.
Practable™ is a cloud-based ecosystem for online practical work.
Examples of two types of Practable™ remote laboratory installations (left: wood for in-room, right: metal for public spaces). Tim has added some credits to those who have contributed so far (and thank you also to those not named – every bit helps).
What is online practical work?
Online practical work is interacting with real or simulated experimental hardware using a web browser.
Screenshot of a live session with a real spinning disk experiment hosted in Edinburgh, UK.
Why adopt online practical work?
For institutions: it has a significantly lower total cost of ownership compared to traditional in-person laboratories. Experiments take up little room, run around the clock, and do not require staff supervision.
For staff: you can design more exploratory tasks; develop active learning and scientific inquiry skills in your students; and conduct authentic assessments.
For students: your practical work schedule is flexible to suit your study and personal commitments; you can work at your own pace, at any time of the day.
Why choose the Practable™ system?
For institutions: long-term costs are predictable because the system is fully open-source, avoiding vendor lock-in. Use our services, or set up your own.
For staff: you can get started at a very low cost, well within the levels of annual lab maintenance budgets. Benefit from experiments created by other users, then add your own customisations and features to share with a community of like-minded colleagues.
For IT teams: in our architecture, experiments connect to a cloud-based infrastructure using standard web traffic (https:// and wss:// connections to port 443 via TCP) so they can be hosted on your standard internal network WITHOUT needing any special permissions or public IPv4 addresses. Students can connect from anywhere, including when they are on-campus without needing any changes to your institutional firewall settings.
How do I try this out?
Our usual public experiments will be made available again after they have completed their current tasking.
Screenshot of the booking page in December 2021 showing two publically-available experiments – what’s on offer will change depending on operational requirements.
How do I get started on my own experiments?
All of our code is open-source, and available from our organisational repository. We’re still working on the features, tooling and documentation required to facilitate adoption by other users, and welcome collaboration with early adopters who like to understand how things work. Our interfaces are written in javascript using the Vue.js framework, our servers are written in golang, the hardware is controlled by Arduino firmware written in C/C++, with printed circuit boards designed in KiCAD and custom structures designed for £D printing and laser cutting.
If you have an urgent need to access experiments or set up a laboratory, then please contact Prof Tim Drysdale. For any other discussions, we welcome your interest no matter what timescale you are considering adopting online practical work – please contact our support team in the first instance.
No, not the infinite impulse response filter, but what digital tools do for us, and against us – the wrong tools are as bad or worse than no tools. Free speech is in the tooling, not the content.
It’s a bit of a cliche to quote Marshall MacLuan when discussing digital technologies, but his insight that a new medium “roughs up” a society by its mere existence is apt
McLuhan tells us that a “message” is, “the change of scale or pace or pattern” that a new invention or innovation “introduces into human affairs.”
The scale, pace and pattern of digital technologies means they are now, and will become moreso, the primary means of our expressing ourselves in many spheres of life. And if not the primary means, certainly an enabling/disabling means. Even a traditional analogue sculptor is likely to order some tools or supplies online.
Why does this matter in Academia? A key role of research in academia is to identify and solve societal, technical and medical problems before they crop up in the future, or at least put in place the means to rapidly respond to surprises we might receive. For example
“Early efforts by scientists at Oxford University to create an adenovirus-based vaccine against MERS provided the necessary experimental experience and groundwork to develop an adenovirus vaccine for COVID-19.” – Dr. Eric J. Yager, Albany College of Pharmacy and Health Sciences in Albany, NY
We usually don’t have the time to start working on a problem when it manifests – imagine if we had to wait 10-15 years for covid vaccinations, rather than just one year due to the headstart from MERS.
Quite often these subject-specific results can be adequately expressed via the traditional route of disseminating papers, videos, and datasets, so the existing digital tools for dissemination are at least broadly adequate. And research communities around the world have a long-standing capability in developing the new experimental apparatus they require, using a combination of off-the-shelf and custom equipment and software. In the humanities, some research areas require the creation of new digital tools, and researchers undertaking this task are appropriately skilled.
Yet when we consider the other role of Academia – to produce graduates with attributes that maximise their potential for solving the future problems of the world, we start to see a bit of an issue emerging. Unlike the research world, the teaching sector is heavily reliant on external software and has less of a culture of build-it-yourself-when-needed (these tasks often go in the too-hard basket, or the can’t-be-resourced basket). This is a supposedly pragmatic response to the issue of the scale, and risk of delivering a teaching experience to many students. But it does not let us avoid the core problem. It is a short-term response that creates a longer-term problem. Why? Let’s start by considering an outrageous example.
Imagine if Microsoft and Adobe overnight decided that we should not use the colour green in any document created with their systems. We would have to give up using green, or learn to use the excellent open-source tools for photo-editing and drawing such as GIMP, Inkscape and OpenOffice. Imagine the fuss! Clearly, no commercial supplier would take such odd action. Yet, what if as thought leaders in the world, there becomes a new value, or principle that is so important to academia, or more likely, a particular institution, that cannot be implemented/expressed/actioned with the existing software they use. What if their inability to express that is as distressing as not being able to use the colour green?
This could occur if we want to start living our academic values in a more consistent way. For example, should we wish to develop a new approach in education that is not catered to by the existing externally-supplied software, or even just tweak something that is not culturally appropriate, then we face a brick-wall of uneditable black box code.
Since it costs money and time to create, implement and test a software architecture with flexibility – knowing what to keep constant is a key skill and those choices are influenced by the culture, values and philosophies of the architect. So what happens when that choice doesn’t work out for other users? For example, if we have a grade reporting system that shows traffic lights to represent pass-fail, then a single threshold is insufficient because the pass/fail mark varies by country, institution and study level, so you can find institutions for whom a pass is 40% in the UK, 50% in the USA, and 60% in China. A system hardwired for US courses is inappropriate in many UK and Chinese institutions. It might even be quite difficult to retrofit that change when reported to the creators. So, do you give up on traffic lights, or create your own software, or wish for a world in which things were open-source and you could edit/tweak and adjust what you need, when you need it?
Did you start to sweat at the risk of making changes to the codebase, testing them, rolling it out, and running a custom service? How is that different to running a University printing press back when pen and paper was the norm. We managed the transition to publishing, now we need to manage the transition to the academic sector being able to create, modify and operate its own digital tooling where it needs to.
This is important in higher education where the development of graduate attributes not currently assessable with examinations (probably marked in Gradescope) will more than likely require new digital tools with culturally-specific features that vary by subject, level, institution and country. The external supply of what we need will at best severely lag our demand, and incompletely support our needs, if we leave it to market forces to create. The alternative is to be able to create the novel digital tooling we need within the sector, using open source licenses, so that others can modify to suit themselves, without having to start over. What do we need to do? I have some thoughts on the digital literacies helpful to STEM education developments here.
The famous physicist Richard Feynman once said “There’s plenty of room at the bottom” – in fact, he gave an entire talk about it. Perhaps a similar sentiment applies to digital education. This post arises from remarks I made during a presentation to the University of Edinburgh Learning Technologists on 26 April 2021, at an internal event.
If you are a learning technologist, or learning technology developer, or otherwise active in the space of helping academics do digital things with their teaching, then remote laboratories are an area you should start considering now. There’s time to develop and enhance your digital skillsets before they become mainstream.
They open up pedagogical opportunities that are either new, or we think used to exist, but are likely to have been squeezed out by resource constraints, such as:
reflective learning
student-led explorative learning
learning difficult or counter-intuitive concepts
authentic assessment
student co-creation
answering questions via interactive live demonstrations
These opportunities are created because:
it’s cost-effective enough to provide spare capacity for students to spend time doing self-directed exploratory learning
it’s digitally mediated so you can develop assessment methods that draw on the flow of data between the lab and the students, rather than relying on the students writing up yet another report.
students can create their own experiments, and therefore learn by teaching others.
the experiments are always online, always accessible.
What is a remote lab?
There are a number of different possibilities on a spectrum from real-time interaction with real equipment, all the way through to virtual and simulated labs ….
real-time interactive experiments with a lab sheet
real-time interactive experiments without a labsheet
real-time interactive experiments either
solo
in a group (working together on same kit, or different)
with a tutor/demonstrator/staff in digital attendance
batch jobs (for using one piece of kit to do lots of fast experiments for lots of students all around about at the same time)
pre-recorded real data replayed as if collected live – this takes some effort to set up, but can be done by all students simultaneously
simulated data (mathematically generated data, either in advance, or live, depending on the particular mechanisms you are working with)
Our remote labs don’t require any special hardware interface boxes, just as long as there is some form of computing device which can run our software that manages the data and video streaming – and that is more than adequately handled by a Raspberry Pi 4 B (we use 4GB RAM but 2GB would be fine).
Our experimental setup uses widely known hardware such as Arduinos and Raspberry Pis, and our cross-compilable streaming software.
Use cases:
A number of use cases come to mind immediately – you will think of others too. Making the campus a playful science museum, accessible remotely and by those physically present is one of the great things I look forward to. Here’s a list of some uses:
Teaching
demonstrate important principles in contact sessions by screen-sharing an experiment
develop experiments for use by students on your course to collect and analyse data, preparing a report for assessment (I know I just said you didn’t need to, but this is a good starting point!)
set students group-work that requires jointly planning and carrying our experiments on the same piece of kit
set students group work that requires them each to individually plan and execute experiments on equipment with different parameters (size, weight, etc), and compare notes to develop an overall model of a phenomena
set students group work that requires diverse range of experiments to be carried out, in order to approach a problem from multiple angles
students explore operation of equipment out of curiosity, prompting questions in class
students ask staff questions, even unanticipated ones, which can then be answered with a live interactive demonstration using experiments found in the catalogue
students send in samples to analyse e.g. via remote microscope
students develop new experiments (e.g. senior year design it, a mid-year builds it and a junior year uses it)
share experiments with colleagues around the world
modify other colleagues’ experiments to better suit your own teaching needs
develop your own user interfaces and teaching materials to depend your own understanding
allow others to access your equipment using their own user interfaces and materials (with suitable safety measures in place so the hardware can protect itself no matter what user interface is in use)
Impact
Research groups make their prototypes and demonstrators available online for sharing with other academics, industrialists, commercialisation partners, and for demonstrations in advanced classes
Outreach activities allow students from schools to work with university-level equipment (perhaps with a different user interface to match the activities they will do)
recruitment – a single ambassador can connect every student in the classroom to an experiment in a subject of interest to them – no need to take equipment in a car or van anymore
public engagement – run events where the audience work together on individual experiments and share results to form overall trends (e.g.
characterise chaotic double pendulums, or
control multiple ground penetrating radar robots to piece together an archeological dig, or
control individual vehicles in an arena to explore swarm dynamics and artificial intelligence.
contribute to teaching at your local schools, further education and higher education establishments, and vice versa
entertain and inform visitors on campus
What about this room in the digital?
There are at least three distinct ways to to contribute ….
Design
unpack course intended learning outcomes (ILO)
identify pain points in current delivery (e.g. lab restrictions, etc)
identify “longed for” opportunities
come up with creative experiment designs to target specific ILO that can be addressed by remote labs, bearing in mind pain points and desired changes
create supporting materials for academics and students where needed (designing the sessions etc)
Deploy
provision and arrange access to experiments and user interfaces for each class as required
handle support requirements that sit somewhere between purely academic issues, and purely equipment issues
check, collate, track and report on usage analytics both for pedagogic and accounting purposes
arrange extensions, access to alternative equipment and provide advice on experiments that could be used
Develop
There’s plenty of room here – if you know / develop Javascript and HTML5 skills then there is a huge amount you can do to create and enhance new experimental activities with existing hardware. Going further, if you do embedded systems, you can make new hardware, and if you do web server development or operations, you can enhance and evolve the infrastructure of the system itself. Some specific points:-
Design and commission new user interfaces from web developers with the necessary Javascript & HTML5 skills
Modify and remix existing user interfaces to suit academic and student needs (we’re using vue.js, which is relatively straightforward but also capable)
Perform tech testing of new interfaces on different combinations of VLE, browser, computing equipment etc where that differs from testing by anyone who developed the experiments originally
Commission or indeed directly implement additional experimental instances from existing open-source hardware designs (e.g. order printed circuit boards, populate with components, download and install the firmware, build and connect the hardware)
Install and configure streaming software on Raspberry Pis
Manage a fleet of experiments using the management interfaces
contribute to server and booking system testing, development and documentation (currently in Golang).
Summary
Remote labs are going to become mainstream in the near future. There is a great deal of scope to add value in the adoption of existing experiments into courses, as well as developing and evolving the activities, and even the experiments. To get involved on the digital side is relatively straightforward, because well-known ecosystems are being used, such as Vue.js interfaces in Javascript, Arduinos for hardware, Raspberry Pis for the streaming, and golang for the servers. The management tools are currently pretty sparse to non-existent, but will develop in a similar direction to VLE management tools (but also with APIs if you like scripting). There is time to develop additional skills in this area and jump on the wave – there’s plenty of room in the digital.
Over the last few weeks, we’ve been running a dozen spinning disk experiments for the 250-strong Controls and Instrumentation 3 Course, which is led by Dr Aristides Kiprakis from the School of Engineering at the University of Edinburgh.
Here’s an introductory video I prepared for the students, which shows the experiments, what is in the boxes, the interface, and demonstrates the real-time nature of the stream.
Here are some assorted fun facts about the firmware (of greater or lesser consequence!)
5ms time step in the PID loop (reporting to user every 4th step)
7 different weights of disk
10V maximum motor voltage
12 different disks available simultaneously to this class
21 states in the firmware’s Finite State Machine
24/7 running – experiments available around the clock
43g minimum disk weight
110g maximum disk weight
250 number of students in the class (approx)
500 pulses per revolution in the encoders (2000 pulses effective)
1453 lines of C/C++ code in the firmware
4300 RPM max spin speed (approx, depends on disk)
We’ll be coming to a close of this run soon, when reports are due. More updates after that! Meanwhile, here’s the closing credits screen students see when their session ends:
TL;DR: Existing remote laboratories typically have trust issues, and it’s holding them back. Proposal: Use a zero-trust philosophy in the equipment side of the infrastructure (via UMA2.0) so as to ease the growing pains of adding new experiments by other people, and enable widespread adoption.
Existing remote laboratories typically have trust issues, and it’s holding them back. Holding them back from becoming mainstream educational tools like virtual learning environments, exam marking systems, collaborative discussion forums, electronic voting systems and so on.
I’m not talking about how to trust (authenticate) users, because that is a solved problem. But rather, how to trust (authenticate) experiments. So far, most people connect up all their experiments behind a firewall, so that internal communications between experiments and management software can be trusted without further ado. Your carefully-developed experiments are right there where you can trust them to co-exist peacefully with each other and the management servers.
But you know just how badly things could go wrong if you let someone else put a bad experiment in there, and you are probably also worried about just how much work it would take to expand to a multi-site network where you can’t virtually add everyone to your protected sub-net. All of a sudden, you’ll end up acting like Jack Byrnes (Robert De Niro) in “Meet the Fockers” and your future collaborators will feel like this:
If you are not in the circle of trust you don’t get to play (Image source)
Before you know it, adding a new experiment to someone’s lab becomes as emotionally and logistically fraught as making an ill-judged attempt to pledge to a campus society. Whose rituals are now mostly banned, by the way.
Tim D.
Is there another way?
It’d be a whole lot better if someone could just get started by reading about it on the web, downloading some standard code, to run on some standard hardware, and try out being part of your lab, without you having to lift a finger. Sure, you might label them as “community tier” experimental supplier, to distinguish them from your own experiments running in some super-expensive server room with air-con and backup-power. But they got to play without any of the pledging nonsense.
The moat is no good once the bad things are on the inside Image Source
Once the castle (sub-net) is full, you can’t grow anymore. So what do you do? Start over with a modern architecture that doesn’t trust (almost) anything, then you can grow until your heart is content.
Limited-growth-model
Mainstream-model
users
untrusted
untrusted
experiments
trusted
untrusted
management software
trusted
untrusted
The way of the future is not to trust (almost) anything
How?
I propose that the answer is to apply UMA2.0 (user-managed access) principles to the experiments. The experiments have to validate themselves to the system in a way that protects them and the system even if they are hosted in an office, or an airplane, and whether they are owned by someone you know well or someone you’ve never even spoken to. Even most of the management software is not trusted, in that we explicitly permit each helper to do exactly the management tasks we need and no more. Then lots of complementary approaches can live alongside each other, without any danger of a bad actor running amok inside the moat.
Ah, happy days. I’ve twenty penduino experiments stacked in my living room. They’re simple but important experiments. You turn on an electromagnet to make the pendulum move.
The swinging pendulum is a classic introductory example of simple harmonic motion. The apparent simplicity of pendulums belies deep roots in our scientific history, having played important roles in:
Thanks to pendulums, we know the earth is solid, rotating, how to get around it, and what time it is when we get to our destination. So what does a pendulum actually look like in action?
Recording the angle of the pendulum produces a sine wave, linking this fundamental trigonometric function with one of the most fundamental forms of motion in the physical world. In this example, the height of the swing is building up, so the amplitude of the sine wave is gradually increasing from left to right in the plotted data. You can see the rounded peaks and troughs in the data because because the pendulum has to slow down to change direction (the same way a ball thrown in the air does).
These electromagnetic pendulums also allow you to explore fundamental electromagnetics principles such as Lenz Law . The pendulum stops swinging faster if you “load” it by short-circuiting the electromagnet. If all that wasn’t enough physics, then we could add a second joint to the pendulum, and explore chaos. Double-jointed pendulums are an experiment for another day, though! I’ll leave you to explore the physics of pendulums some more on your own if you wish, while now I’ll move on to the remote labs stuff.
Remote labs at scale
Setting up a remote lab with lots of copies of the same experiment requires a slightly different mind set to setting up just one experiment. For a start, you don’t want to be repeating the same tasks over and over again by hand, for each of the copies of the experiment. Not only is it tedious, but it also increases the chance of making an error. Secondly, there are ways of thinking about pools of experiments that help your laboratory be more resilient to the vicissitudes of hardware.
I’ll pick up more on these themes in future posts – but for now, I am excited to have a working batch of 20 pendulums to develop and test out the software infrastructure with.
Acknowledgements
My Dad (Alex) designed the original laser-cut wooden box for me over one Christmas holiday 2018-2019. Here’s one of the original boxes from the first run of four.
This year the Head of School Prof Conchúr Ó Brádaigh approved the spend to make this large batch of boxes (my thanks also to my Director of Discipline Dr James Hopgood for his role in supporting this). Chris Sturgeon’s technical team jumped on the task of getting the large batches of boxes made up, with Andrew Brown designing the new-look pendulum, tweaking the boxes for laser production, and coping with the tedium of supervising the laser over and over again (even when things got smokey). Together with Calum Melrose, they bashed out over fifty boxes and forty pendulum kits so far and are now working on another thirty controls experiments. The pendulum design originated from Tony Gasparovic. Michael Merlin suggested a new control scheme for the pendulums, which achieves variable swing height and braking. David Reid converted my Veroboard version into a PCB design, which Alasdair Christie and Iain Gold populated and cabled. Richard Scott and Doug sorted out the lighting (easiest lighting setup with the connectors Doug chose). A number of others have been helping other aspects of this programme along too, and I thank you too – more on you later!
Andrew (right) and Calum (left) hard at work designing and producing remote labs experiments in our mechanical teaching laboratory. Top chaps! This photo went out to all our students in a recent email update.
