Categories
Curator Embedded Systems Developer Learning Technology Developer Provider User Interface Developer

There’s plenty of room in the digital.

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.

We need remote laboratories regardless of any physical distancing constraints, as we pointed out before the pandemic: https://www.tandfonline.com/doi/full/10.1080/23752696.2020.1816845.

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.

Categories
Examples Experimenter

Control that disk!

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.

Tim standing with remote labs boxes

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:

Categories
System Developer

Experimenting with trust issues

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.

Is this even possible? Sure it is. If the chocolate factory can go fully zero-trust then that proves the validity of the concept. It’s all about getting away from the castle-and-moat thinking.

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-modelMainstream-model
usersuntrusteduntrusted
experimentstrusteduntrusted
management softwaretrusteduntrusted
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.

Conclusion:

Ironically, it’s a lot friendlier not to trust.

Categories
Curator Examples Experimenter Provider

The First Twenty

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.