Implementing Online-Hardware Hybrid Labs
Using the Raspberry Pi Platform for remote learning in a Measurement and Instrumentation course
Srikanth Sugavanam, Assistant Professor, School of Computing and Electrical Engineering, IIT Mandi; Erwin Fuhrer, Assistant Professor, School of Computing and Electrical Engineering, IIT Mandi.
(Both authors contributed equally to this work).
Cover image shows a teaching assistant (TA) conducting a fully remote, live-streamed, online-hardware lab session. A Google Meet session is running on the left hand side, with a remote team logged in along with the TA. One of the remote users is logged into the Raspberry Pi on the right and sharing their screen in the Google Meet session, while a video camera live-streams the experiment in action.
Implementing Online-Hardware Hybrid Labs by Srikanth Sugavanam, Erwin Fuhrer is licensed under CC BY-NC 4.0
Abstract
This article provides the philosophical underpinnings behind the design of a Raspberry Pi-based online-hardware hybrid Measurement and Instrumentation Course, offered over the Spring semester 2022 at IIT Mandi. We detail the set up, teaching approaches adopted, assessment modalities and some observations and reflections. We also provide all the instructional materials and codes in an open-source GitHub repository.
1. The Dilemma
In the winter of 2021, Erwin and I were confronted with a problem.
We were both tasked with teaching a 4-credit Measurement and Instrumentation lab-based course at IIT Mandi. The problem was not the course content, but the news that Omicron was gaining momentum in India. From the trends observed across the globe, we knew that the Omicron mutation spread much faster, but also was less harmful and the infected had quicker recovery times. In December, the students were still off-campus, and were being called back in batches with the goal of having all of them back on campus by the beginning of the semester in February. But as the pandemic was an evolving situation, there was a fair amount of uncertainty on when the full cohort would return. We had to be prepared for the worst case scenario – that the students may be forced to leave mid-course yet again, which may require us to shift our mode of instruction from offline to online.
For a lab-based course.
Then, we also had a strong conviction – the conventional approach of teaching measurement and instrumentation is lecture-driven, aimed to impart essential foundational concepts. There are also well-defined experiments based on off-the-shelf test kits which can be offered to the students for familiarizing with the common components like LVDTs, transformers, motors, etc. Yet, we strongly felt that the landscape of this field of instruction needs a dramatic overhaul.
The success of the Maker movement and its worldwide adoption, supported by the ever-increasing availability of open source codes and engineering designs has broken new ground for the discipline of measurement and instrumentation. Our conviction was if students are exposed to these new and developing tools in a systematic fashion early on in their courses, they can carry over their learned concepts to other courses and projects, giving innovation-oriented thinking a big boost from an early stage.
Herein lay our dilemma – on the one hand, we wanted to train the students in this new way of doing things, but on the other hand the students were not here in person to do it. Hands-on experience with electronics and interfacing gives the students a sense of greater appreciation of the complexities of real-world instrumentation and design problems. Simulations are good for conceptual understanding, but not enough. They don’t give the tactile sense of a heating resistor, or let off the ominous odour of a burning IC.
Beyond this practical experience, we also wanted the students to get used to a very important aspect of experimentation – being comfortable with “not-knowing”. Kit-based experiments can only go so far to give an idea of the workings of a device. But true innovation comes from a place of ignorance, curiosity and uncertainty. We wanted to offer a different kind of a course that would impart to the students the skills of directed exploration – one that would enable them to breach and understand the unknown.
2. The Hardware Challenge – Online or Offline? Hybrid!
Irrespective of the physical presence of the students in the lab, we wanted the students to work with real hardware. Hence the only solution was to implement the course in a hybrid mode. We also decided to design the experiments around the Raspberry Pi (RPi) platform , because it is a single-board computer and a hardware interface integrated into one device. As we were moving from a conventional kit-based training mode to one using Rpi (and as a consequence using the Python programming environment), we knew we had to conceptualize scaffolding activities to teach the students these concepts. Further, we also wanted the course content and labs to move in step as much as possible to allow for maximal transfer of learning between the taught lectures and labs.
We also foresaw some challenges. Firstly, we had to rethink the pedagogy of instruction for the labs as it was going to be implemented online. Remote access and control of the hardware would have to be clearly thought out, as in the end students shouldn’t feel they are running a simulation with some extra steps. We also had budget and time limitations – there was neither the money to get a server and run instances of services like PyScada (https://github.com/pyscada/PyScada), nor the time to implement this. We had to be implementation ready in a month and a half.
3. Our solution
The first decision we made was to stick with the Raspberry Pi platform given its advantages. The next step was to enable remote access of the RPi by the students, so that the students could directly access and control hardware connected to it. We ended up using the VNC Connect software that came with the RPi OS install, which allows remote access of the RPi via a client installed on the remote Windows/Linux system of the students. A key step in enabling this was figuring out how to enable remote-access of RPis connected to the Institute LAN accessible to our off-campus students. Our institute’s Networks team helped us set this up, and got us off the ground in no time.
By the time the lab session started some of the students group were back on campus. The protocol of doing the labs in a hybrid mode was then established as follows – The labs would be implemented by a group of students – some of whom are remote, and some who are present in person. The experiment would be running off a Raspberry Pi that would be connected to the internet. Students who are located remotely would log into a Google meet session on a separate computer, where they would be able to see a live stream of the experiment. Simultaneously, the remote student would log into the VNC Connect session, and share this in the Google meet window. Other remote students can then see both the operations being carried out by the student via VNC Connect, and the experiment via the live stream. Students who are doing the experiment in-person in the labs would then make and adjust the hardware connections, facilitating real-time optimization of the hardware. This way both the in-person and remote team would work hand-in-hand to implement the experiment.
Some groundwork was then needed to enable streamlined functioning of this protocol. Key to the implementation of the experiments was the use of a digital oscilloscope with remote control functionality. We wanted the remote students to control the oscilloscope using Python on the RPi. By luck, our labs already had a Keysight DSOX1102G, so we could use the open-source library Pymeasure which had ready codes for oscilloscope remote automation. The hurdle we had to jump was enabling USB-based serial communication on the RPi, which turned out to be a non-trivial problem to solve. Luckily a whitepaper by Keithley, and a follow-up blog by its author on LinkedIn helped us to configure the RPi to communicate with the oscilloscope via USB. In addition to this, to get the RPi’s experiment ready we had to change its settings and install several libraries. Erwin and I put together a note on GitHub for step-by-step configuration of the RPi. This was then passed on to our four teaching assistants, who configured sixteen instances of the RPi OS on sixteen SD cards that could run on 8 RPi’s. The aim was to implement the labs over two days, where we could support at least 8 groups each day. We also incorporated the use of digital potentiometers so that the students can do resistance and voltage sweeps remotely.
Beyond configuring the RPis and implementing the codes for remote automation, we also wrote and tested some basic example codes for the students, which they could build upon further to complete the tasks. We also wrote a ‘wrapper’ library of functions for the Pymeasure-based oscilloscope remote control functions, so that they would be easier to understand for the students. In essence, the goal of the labs was not to put the students through a coding exercise, but remove that hurdle and get them working with the sensors and on the science as rapidly as possible.
At this point, Erwin and I must acknowledge the indispensable role our TAs had to play towards the implementation of the lab. We had four TAs for the course – Abhishek Singhal and Mohd. Iqbal Ashraf (PhD students), Rajan Shukla and Samarth M (MTech students), and also our lab assistant Shivam Prajapati. We met almost every weekend for a couple of hours before each lab session the following week, playing around with the codes and the electronics. The TAs (barring one!) had little to no experience with the RPi platform, which helped to iron out the kinks in the instruction material and adjusting the teaching pedagogy. They also assisted the students during the lab sessions. Each TA was assigned to no more than two groups. Plus, they had strict instructions not to help the students with debugging their setup, or answer their queries directly. Instead, they were coached to examine the understanding of the students by counter-questioning. Where the students had considerable conceptual shortcomings, the TAs flagged us for support and intervention. The TAs were thus immensely helpful towards the successful implementation of the course – their active approach maintained momentum, and facilitated timely course correction for the students.
4. The Experiments
We decided to offer ten experiments that would cover the basics of instrumentation across disciplines. This was a tough target to hit given the short 4-month time frame of the course. Yet we were able to offer eight experiments that covered the essential concepts of sensor interrogation, instrumentation and hardware interfacing. The first four lab exercises were tailored as scaffolding activities, introducing the students to the RPi and GPIO control via Python using the on-board Thonny IDE. Here we also demonstrated the software-based timing limitations, and introduced the pigpio library based hardware timing controls. Once the students were comfortable with this, we moved on to instrumentation automation concepts by showing them how to control the oscilloscope settings via the RPi. The last scaffolding experiment was the control of a digital potentiometer configured as a voltage divider, and using the oscilloscope remotely to read out the voltage values.
The rest of the labs were geared more towards teaching the students the concepts of sensors, sensor interrogation, and allied physics. For all the labs, a basic instructional material was provided to the students along with some pre-reading. However, the instruction manual did not include cookbook like step-by-step instructions. Rather, it indicated a problem or task that needed to be addressed. The successful completion of the task required that the students read the provided reading material, and also rely on their knowledge of fundamental concepts. The labs were implemented in a team fashion by the students, so the students could rely on the complementary skill sets of their team members to arrive at a solution. Clear task completion criteria were provided for each experiment, where each consequent task dependent on the results of the previous one. This structure also helped the students to keep track of their progress. The reading material also sometimes included some questions that required the students to reflect on the task at hand, prompting to think before they leapt. A pre-lab online quiz tested whether the students had prepared the provided reading material, so that we the instructors could assess the level of instruction and support that would be required by the students for implementation of the labs.
We finally offered the following experiments –
- Lab 1 – Introduction to physical computing with Raspberry Pi.
- Lab 2 – Time of flight distance measurement.
- Lab 3 – Hardware timing and distance measurement.
- Lab 4 – Digital potentiometers.
- Lab 5 – The Wheatstone Bridge.
- Lab 6 – Temperature sensors
- Lab 7 – Pressure sensors.
- Lab 8 – Wind tunnel based velocity measurements.
- Lab 9 – Innovation.
For the final Innovation lab, the students were asked to develop an application by choosing a sensor or actuator from a provided list with supporting material and provide their own experimental objectives (or learning outcomes). Some basic guidelines were provided to help students structure their strategy, and also enable uniformity of assessment across the cohort. The purpose of this lab was to show the students that by doing the 8 experiments, they now possess a core skill set that will enable them to pick up a sensor or actuator from the market place and use it in their own application.
In other words, by the time students reach Lab 8, they already have a good skill set which will then allow them to branch off into an application area of their own interest. Hence, Lab 9 is essentially offered as a self-guided exercise. Thus, one can offer experiments of any nature after Lab 8 as per requirement of the degree course.
The photographs above show one of the first labs, when most of the students were remotely accessing the hardware. There were actually 37 students in the labs that day, with 28 students attending online.
5. Assessment modalities
We had 67 students who were distributed into 12 groups with 5 or 6 group members. Students were assessed both on the basis of their weekly performance in the labs, and in a final written exam comprising of descriptive and conceptual questions.
The lab evaluation had an effective weightage of 70%, while the written exam had a weightage of 30%. Assessment of the lab activity was further sub-divided along the lines of implementation, task completion, and report assessment. The report received a marginally higher weightage than the other components as the students were not given a template, but only guidelines on writing a good technical report. Detailed feedback was provided to each group after they submitted their first report, which helped to streamline the reporting format going forward. This was to promote independent, critical thinking and decision making skills on part of the students. Lastly, a blind peer assessment exercise was carried out after the completion of each lab exercise, where the students could grade their team members on the basis of their contribution. While in most cases everyone gave their team members the top score, a lowered score was a good signal of team dysfunction, which acted as a prompt for instructor intervention and conflict resolution.
The written exam was given at the end of the semester. This was a descriptive, 3-hour examination. Each question comprised of typically three parts, which quizzed the students on basic definitions, concepts, and finally design aspects. The final question was based on the experiments that the students had already done in the lab, so as to establish a link between the taught lecture material and the labs implemented. Answering these questions required a deeper level of understanding of the taught material and also an engagement of higher-level cognitive thinking at the time of doing the experiments. These questions helped us identify and reward the students who were more actively involved and engaged in the course.
7. Some observations
Over the 4-month odd duration of the implementation of the course, we made some interesting observations.
Right at the onset, we saw the need to slow the students down. We saw that they were taking a hit and trial approach for arriving at the expected results. We think the reason for this is the unavoidable time limit on the experiments, as we do need to complete a set of them to cover the curriculum. Thus, even though the task completion criteria were provided to act as milestones for monitoring progress, they shifted the focus on completing the task, rather than understanding the experiment. In addition, this also led to surface learning approaches being adopted by students – they addressed only those aspects which would lead to a completion of a task (as per their understanding).
We had foreseen that the students would adopt such surface learning approaches to a certain extent. To combat this, we incorporated a small pre-lab quiz at the start of each session, that would test them on the reading material provided to them. This primarily comprised of questions that verified whether they knew essential aspects – e.g. maximum power levels, maximum current draw, pin numbers, etc. Yet, as the sessions progressed, we saw ourselves actively asking students to stop and think why they are doing what they are doing. Clearly, the instructor has to be actively involved in the lab sessions, to observe the approach adopted by the students in doing the experiments, and ask some questions that would nudge them to course-correct.
Another aspect we noted with our specific cohort was they were starting to develop a programming-intensive problem solving approach. If the students encountered a hurdle during their experimentation, they would spend more time in checking if there are bugs in their code, rather than reflect the physical configuration of the experimental set up. We think this approach could stem from the hybrid nature of the course itself. As the students started off working primarily on the RPi platform, they believed that all problems could be solved in software, as hardware (in our particular case the ultrasound sensor or the digital potentiometer) shouldn’t be the bottleneck. However as the experiments became more complex, this approach remained.
To remedy this, we started incorporating the use of more physical knobs and buttons in our experiment. For instance, by the time the students reached the temperature measurement experiment, most of them had arrived on campus. We then changed the modality of the experiment. We did not require the use of the RPi. Instead, they had to work exclusively with hardware, and that too from scratch – i.e. mount the Peltier on the heat sink with heat paste, connect a thermometer and voltage source for temperature calibration, mounting the PT100s, etc. The computational/analysis part came at the very end when they had to calculate the temperature coefficient of the PT100. An instructional video and additional material was provided to the students for that particular lab to explain the philosophy of taking that approach. This was based on the understanding that making students aware of the philosophy behind an adopted teaching material is conducive to their higher engagement with the teaching material.
Indeed, while doing the experiment we saw this. The students started thinking of ways to cool the Peltier below the specified lower temperature limit – some resorting to making a water bath using cooler water. Not quite the correct way to do it, nevertheless a well-spirited approach to experimentation that was brought about by an active engagement with the presented material.
The online-hardware mode thus does come with a caveat. This can be remedied if the students eventually do some in-person sessions. Alternatively, instructors have to actively step in and ask the students to stop and think whether the problem that they encounter is a software or a hardware one.
Finally, in our case, we found the need to slightly nudge the students to develop good organization skills, especially when it came to data handling. Several students were taking down data in loose sheets, to be transferred later to spreadsheets, or not storing codes in an accessible way (in spite of being told they would need these in the following experiments). We had anticipated some of these issues, and thus had provided each group their own SD card. This way, at least the codes and materials they generated was localized. On the other hand, a note we had shared about good technical writing practices for writing the report was well taken by several groups. Thus in future iterations of the course, we are considering to offer some support material on how to keep a running record of experiments, i.e., maintain a lab note.
8. Student feedback
This was in general positive. Students appreciated the work put in by us instructors and our TAs in structuring the experiments, and they felt that the course content was highly transferrable. On the other hand, we also had a significant population of students who felt the course was quite hectic, and could be relaxed in terms of the assignment and the number of labs – which we consider as a fair point.
It is well documented that true learning in such fundamental labs arises from a process of iteration. Students need to be provided with both agency and time – the agency to choose the experimental approach and associated parameters, and time to reflect and improve on their performance. While the experiments offered by us create a lot of room for agency, given that there is a curriculum to cover, we indeed had to impose time limits. As mentioned above, this led to some students adopting surface learning approaches. The challenge that thus remains is to restructure the experiments is such a way that agency is retained, the students get more time to reflect and iterate, while also ensuring that the students are able to achieve the learning outcomes as put forth by the course.
9. In summary…
…we learnt quite a lot! One of the good decisions we made was sticking with the Raspberry Pi platform from day one. This allowed us to structure some really good experiments, and at the same time also facilitated the implementation of the remote labs.
Specifically, we could work with any student configuration. One of the problems for our large cohorts transitioning from online to offline mode was it happened in a batch-wise fashion. Such partial presence usually prompts the use of online teaching modalities and simulations tools to progress with the teaching material till all the students are on campus. This results in a significant loss of actual hands-on lab time. However, in our case this question was moot. We could simply run the course in the hybrid mode, and all the students could participate in the lab sessions, working on actual hardware. As the students gradually joined their groups in person, their team members who were attending the sessions in person coached them on the requisite hands-on skills, easing the transition.
Substantial groundwork was required to set this up, but seeing the pay-off we have decided to make all the materials that went into structuring the labs available as open source. The GitHub repository includes codes, wrapper libraries, the materials for instructional use with each lab, and of course the note on configuration of the Raspberry PIs. If you feel there is anything missing, feel free to reach out to us on our Institutional email IDs.
We have also included in the repository a bill of materials for each individual kit. In principle, by making a judicious choice of sensors and actuators, you should be able to build a kit along similar lines for under Rs. 40,000. Do note that we have not included oscilloscopes and computer screens in our list, as these were already available in the lab. The priciest item for us was the Raspberry Pi kit (board and accessories), as used a Model 4 4GB version. It may be possible to use a lower cost version, even a Raspberry PI zero, however we have not explored this.
The Open-Source Initiative has really opened the world to new possibilities of ground-breaking grassroots innovation. If we develop courses and develop instructional pedagogies around this vast ecosystem, and endeavour to deliver this at the initial stages of technical education, we will surely reap its benefits. Our effort in putting together this ‘Online-Hardware’ Measurement and Instrumentation course was a small step in this direction, and we hope that the materials we have created will contribute further to this global movement.
Implementing Online-Hardware Hybrid Labs by Srikanth Sugavanam, Erwin Fuhrer is licensed under CC BY-NC 4.0