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