Practable™ is a cloud-based ecosystem for online practical work.
What is online practical work?
Online practical work is interacting with real or simulated experimental hardware using a web browser.
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.
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.
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.
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.
On Wednesday 5th May 2021, the University of Edinburgh is hosting an event for prospective undergraduates to give them a taste of practical lab work here in the School of Engineering. Under current travel restrictions, the students are unable to physically be on campus; however, the new remote lab system, designed and built in-house, will allow students to remotely interact with hardware and gain experience of what future hybrid learning may look like in STEM education. We’re also keen that everyone else who is interested in remote labs can have a go too – so this blog post is both for the students coming to our event, and for anyone who has made their way to this site who wants to try things out themselves. We’ll post a link here when general public access to the lab is available.
Two types of experiment will be available for students to explore: a simple pendulum remote lab and a spinning disk with proportional-integral-derivative (PID) controller (both real and simulated hardware). These remote and simulated labs give students the opportunity to explore these systems without the physical and temporal constraints of a traditional lab environment – in other words, they can do practical work from anywhere, at a time that suits them. The user interfaces are designed to encourage open exploration of the hardware, to provide a range of modes to control the equipment and to provide various methods for collecting and analysing data. Analysis can occur within the web app itself using the ‘Table’ and ‘Graph’ tools, including comparison of data to theoretical models with the ‘Function Plotter’. Data can also be downloaded (as a .csv file) for further exploration outside of the interface.
We’re used to seeing new users enjoy controlling something at a distance, so we know it is fun – the real time connection is important for making that emotional connection. When it comes down to getting actual work done, there is still some work to be done on making them seem a little less, well, … remote! We are actively researching student perceptions of different interaction modes. One such mode is having users make analogue measurements of hardware via UI tools, and this can be seen with the ruler and protractor in the pendulum remote lab. Although accuracy and precision could be viewed as a benefit of remote over traditional (proximal) labs; perhaps it is a disadvantage when the intentions of practical work include student skill development and an understanding of experimental error. This is one of the great strengths of remote labs – each experience can be tailored to give the kind of intended learning outcomes that are most important. This adds to the design burden for the creators, and there is a lot of rich work to be done here. In short, though, all of this will lead to design changes over time which enhance the experience for staff and students alike – meanwhile, we get to enjoy the immediate benefits of convenient and immediate access.
Our event is really just about letting students connect to the experiments and have a look around the interface. We encourage student-led exploration of the remote labs – whatever you want to do, is good. And we also want to show some of the depth that you can get to even with apparently simple experiments. So for anyone wanting to try getting into the details, below you will find some information on the lab hardware and then outlines of a few in-depth activities for the pendulum and spinning disk labs. More information on the remote lab UI and individual UI elements can be accessed at:
The electromagnet (or coil), when energised, repels the magnet affixed to the bottom of the pendulum. When the coil is not energised, it is open-circuited and has no effect on the pendulum. We can selectively energise and de-energise the coil in order to control the swing of the pendulum. Switching the coil on when the pendulum is receding from the centre point has the effect of repelling it and maintaining or increasing the swing height – this is the behaviour in ‘Start’ mode. Switching the coil on when the pendulum is approaching the centre point has the opposite effect, acting as a brake that slows the pendulum – ‘Brake’ mode. Driving or braking only occur within a limited range of positions around the zero point. This range can be controlled with the drive and brake settings on the UI. The timing is illustrated below:
‘Free’ mode leaves the coil open-circuited and de-energised throughout its motion, therefore the pendulum has no drive, but does have the damping effect of air resistance and friction (whilst in motion). In this mode the pendulum will come to a stop slowly. ‘Load’ mode will de-energise the coil, but also short-circuit it so that a current is induced in the coil as the magnet swings past, generating a field around the coil that opposes the pendulum’s motion. This mode brings the pendulum to a stop faster than ‘Free’ mode, but slower than ‘Brake’.
Large amplitude oscillations may cause the encoder to miss position counts and after a long time the drive may be out of sync with the pendulum motion. The ‘Cal’ (calibrate) mode waits for the pendulum to stop and zeroes the encoder position at the equilibrium point (hanging vertically downwards).
More information on the pendulum experiment, and the firmware that is run on the Arduinos controlling the hardware, can be found at:
The spinning disk remote lab consists of a disk attached to a DC motor with an optical encoder for measuring angular position (and to calculate angular velocity). An Arduino runs the firmware for controlling the motor and a Raspberry Pi is used for streaming video and data.
The spinning disk can be put into 3 different modes: voltage, position (PID) and velocity (PID). Voltage mode has no feedback loop and simply allows a voltage to be applied to the motor (either as a step or ramp input). The other two modes use a proportional, integral, derivative (PID) controller in order to set the motor to a specific position or velocity. The feedback loop is shown in the diagram below. The plant in our case is the motor/disk system. r(t) is the set point (either the position or speed we set our disk to) and y(t) is the measured value (of position or speed). The error, e(t) = r(t) – y(t), is used to calculate a correction based on the PID terms to apply a new voltage to the motor (plant).
More information on PID controllers in general can be found at:
[Note: the README has not been updated to reflect the current state machine in the above repository]
Pendulum Activities
1. Period vs amplitude
Systems that are governed by simple harmonic motion have a time period that is independent of the amplitude of motion. Is the compound pendulum simple harmonic over all drive strengths?
Find the smallest drive that gives you oscillatory motion. Measure the time period for this oscillation as accurately as you can.
Continue increasing the drive by a few percent and measure the period each time.
Does the period remain constant?
The period of a simple pendulum is calculated using:
What is the equivalent length of a simple pendulum that would give the same period as this compound pendulum when it is performing simple harmonic motion?
How does your measured length compare to the actual length of this compound pendulum?
Use the ‘Trigonometric’ function plotter to model the pendulum oscillation. How does the theoretical time period compare to your calculated time period?
2. Estimate of energy loss per oscillation
The total energy of the pendulum can be measured as its kinetic energy through the equilibrium position (when potential energy is 0). Kinetic energy is calculated as:
Where I is the moment of inertia of the pendulum and ω is its angular velocity. We don’t easily know the moment of inertia of this compound pendulum, but we want to calculate the fractional change in energy over one swing and this information is therefore not necessary.
Drive the pendulum at around 70%.
Set the pendulum to ‘Free’ mode.
Measure the speed of the pendulum through the equilibrium position on a swing and then the next swing.
What is the fractional change in the kinetic energy through the equilibrium position over one swing?
Estimate how many swings the pendulum should complete before stopping?
Count the number of swings the pendulum actually takes to stop and compare to your calculation? Is there a difference? Why?
3. Damping coefficient
When set to ‘Free’ mode the pendulum will swing under the effects of air resistance and mechanical friction. From the moment the pendulum is set to ‘Free’ the amplitude of the oscillation can be modelled using the following equation:
Where A(t) is the amplitude at time, t, A0 is the initial amplitude and b is the damping coefficient.
Set the drive to 100% and wait until the pendulum reaches a consistent amplitude.
Start recording data on the graph and press the ‘f’ key at the same time.
Stop recording once the pendulum reaches a low amplitude oscillation.
Use the graph (and table if you like) to identify the amplitude and time for each peak of the decay curve. Note these down.
In spreadsheet software, can you show that the amplitude decays according to the above equation and find a value for the damping coefficient, b. [HINT: taking the natural log of both side of the above equation will give you an expression for ln A against t, how can b be found from a plot of lnA against t?]
Check your calculated value using the exponential function plot on the graph.
Spinning disk PID controller (simulated)
1. Step response of motor
Motors can be parametrised by their gain and time constant for a step input of voltage. The gain of a motor can be calculated as the increase in angular velocity per unit volt applied. The time constant is measured as the time taken to reach 63% of its maximum angular velocity.
Using the orange disk, make sure that ‘Select mode’ is set to ‘Speed open loop’ and that Input mode is set to ‘Step’.
Set the voltage slider to any value you like and note it down.
Click ‘Set’ and wait until the graph levels out to a constant speed.
Calculate the gain of the motor:
Calculate the time constant as the time taken to reach 63% of the maximum measured speed.
Select the plot function ‘Step (1st Order)’ and input the values that you calculated – step size is your input voltage, K is gain and τ is time constant. Just leave t0 as 0. Does the theoretical step response (red curve) look similar to your calculated values.
Repeat for the green and/or blue disks – which values remain constant and which change?
2. Proportional Controller
PID controllers provide feedback control in systems such as automatic speed and steering in cars. They do this by measuring the error in the current output of the system compared to the desired set point and feeding this back to the input of the controller.
Using any disk, select mode ‘Position PID’ and Input mode ‘Step’.
Leave the PID Parameters at the default values (Kp = 1, Ki = 0, Kd = 0).
Set the step size to 1 rad and click ‘Set’.
Wait until the graph stops plotting or the oscillations have reached a small value and then click ‘Stop’.
Describe the behaviour of a proportional controller.
How long did the disk take to reach the first maximum? What angle was the first maximum? Note these down.
Increase Kp a few times and make the same measurements as above.
What happens to the time to first maximum and the maximum angle as Kp increases?
Extension: What effect does changing the Ki and Kd parameters have on the response?
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).
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:
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.
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.