Categories
Examples Experimenter Uncategorized

Exploring the remote labs

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:

https://static.practable.io/info/spinner-1.0/index.html

How the labs work

Pendulum

Available modes in the Pendulum remote lab

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:

How the pendulum is electromagnetically driven and braked.

‘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:

https://github.com/timdrysdale/penduino

Spinning disk PID controller

Overview of the spinning disk hardware.
Modes available in the spinning disk PID controller

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).

PID controller feedback loop

More information on PID controllers in general can be found at:

https://en.wikipedia.org/wiki/PID_controller

And code for running our spinning disk PID controller can be found at:

https://github.com/dpreid/pidcontroller

[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?

Categories
Learning Technology Developer Opinon

Digital filtering

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.”

http://individual.utoronto.ca/markfederman/article_mediumisthemessage.htm

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

https://www.medicalnewstoday.com/articles/how-did-we-develop-a-covid-19-vaccine-so-quickly#Other-coronaviruses

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.

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.