Abstract

The aim of this study is the development of a new teaching approach with a mobile teaching suitcase for computer science teaching, to teach the digital content of the 21st century curricula in practice, and to record and analyse the learning successes of the course participants in a bachelor’s course in application computer science, semester 1, on the subject programming part 1. For this purpose, primary data from a survey, which was conducted prior to the course on the current level of knowledge regarding information technology content of the participants, is used as a starting point. First theoretical content on the basics of the programming language C and Python and theoretical technical basic knowledge about the single-board computer (SBC) used is imparted. Second, selected to the knowledge level of the participants, a model vehicle controlled by an SBC, equipped with various sensors, with previously defined capabilities is planned, implemented, and tested in a workshop with a limited preparation time in presence and self-study. The implementation is accompanied by a task that describes the demanded capabilities. The success of randomly selected groups of 2-3 people are recorded and evaluated by video documentation. The experience and previous education of the group participants is considered, in order to record the progress of the participants. The study was realised as a mixed-method study according to Creswell by combining quantitative and qualitative methodologies in a deductive way. The study concludes with a summary and an outlook.

Keywords

21st century skills, STEM Didactic, Education Tools, Computer used in Education, Innovations in Higher Education

Introduction

In last couple of years, teaching of digital content and processes has found its way into the curricula of primary to upper secondary schools. The implementation of teaching of digital content in the subject area of pedagogy therefore requires new technical aids and special requirements for the hardware and especially for your environment (Nothacker & Lavicza, 2020). In order to meet the new requirements, most institutions keep a large number of hardware in form of personal computers, which are linked by servers via a network. This requires a lot of technical effort and support for the institutes, provision of special technically rooms and stuff, as well as associated increased costs. However, the server landscapes are not only costly and time-consuming, but they are also more prone to errors and thus tend to hinder the smooth running of the courses.

This is precisely where the study comes in and shows lecturers and institutes a way of using mobile computer science teaching cases to design modern computer science teaching flexibly and efficiently without cost-intensive investments in the form of hardware, software and personnel and special IT rooms with little technical effort.

The following questions are to be answered in this study:

What does a teaching concept have to look like in order to be able to use a mobile computer science teaching suitcase efficiently?

What are the advantages and disadvantages of using a mobile teaching case for institutions, lecturers, and students?

Research Design and Methods

In order to be able to fulfil the objectives of this study, the “Mixed Method” according to Creswell is applied (Creswell, 2014, S. 50). The questionnaires were scanned and coded with the software MAXQDA 2020 Analytics Pro (MAXQDA). The graphics were created with a data export from MAXQDA (MAXQDA 2021 – MAXQDA | All-In-One Qualitative &, 2021) in combination with Microsoft Excel (Microsoft, 2021).

The study is conducted in 4 steps. In step 1, the data from the knowledge survey is collected quantitatively and qualitatively, coded and binarized according to Mayring (Mayring, 2014, S. 26). The findings are presented in network diagrams. In step 2, the content of the teaching case and the teaching concept, which builds on the data from step 1, are described. Particular emphasis was placed on targeted knowledge transfer in order to bring all participants to the same level of knowledge. The students should be enabled to deal with new techniques independently, to use them sensibly and to reflect critically (KMK, 2016, p. 49). In step 3, the teaching concept developed in step 2 was implemented with the teaching suitcase described in step 2. The results were documented with videos. In step 4, based on the results and notations from steps 1-3, the advantages, and disadvantages from the point of view of the teaching assistant, the students and the institute are worked out and presented in tabular form. Figure 7.1 shows the process of the study graphically.

Figure 7.1. Research description Step 1 to 4

Teaching informatics without Personal Computers

Knowledge Analysing

In order to find out the level of knowledge of the students, the methodology of the survey is suitable. According to (Fink, 2003, p.1) a survey represents one of the most often used techniques of collection information from or about people to describe, compare, explain, or predict their knowledge, attitudes, or behaviours. Surveys are also used for student performance measurements (Phillips et al., 2013). This is done with a common data research method, a questionnaire. The questionnaire was developed in such a way that one can especially check the level of knowledge on digital contents which should have been learned in the school types before the study and has been learned beyond that.

Structure of the Questionnaire

The questionnaire in this study is a double-sided DIN A4 paper questionnaire, which was filled out by the students within approx. 10 min before the first lecture hour. In addition to the standard contents, such as date, gender and age group, the questionnaire contains key topics from which the level of knowledge of each individual participant can be derived. The topics were “basics of computer science”, “hardware”, networks, operating systems, application software, “programming/ programming languages”, “file systems”, “areas of interest” and “self-assessment”. Of particular interest in this study were the topics “programming/ programming languages” and the topic “self-assessment”. For each of the topics mentioned, the student had to rate their knowledge with a weighting of 1-5, where “1” stands for “very good”, “2” for “good”, “3” for “moderate”, “4” for “poor” and “5” for “not at all” knowledge. The questionnaire is attached in the appendix A and B.

Results Questionnaire Analysis

The course was attended by n=28 students. All 28 students (100%) filled out the questionnaire, of which 4% were from Hungary (HU), 4% from Mecklenburg-Vorpommern (MP), 38% from Bavaria (BY) and 54% from Baden-Württemberg (BW). The proportion of students between 16 and 20 years of age was 67.85%, and the proportion between 21-25 years of age was 32%. The proportion of female students was 14.3%, the proportion of male students was 85.7%. None of the students belonged to the diverse group. 21.4% of the students did not attend a High School but had an ISCED Level 3 qualification equivalent to university entrance according to the International Standard Classification of Education (ISCED). In this study, programming languages and tool skills were of particular interest. The percentages are shown in Figure 7.2 and Figure 7.3.

Figure 7.2. Results – Knowledge Programming Languages/Tools (n=28)

Figure 7.3. Knowledge Programming Languages/Tools (n=28)

In Figure 7.4, the programming language skills that should be aquired from the upper school curricula were singled out. 25% to 32% of the respondents stated that they had only moderate to poor knowledge of the programming languages C, C++ and Python; 25% to 29% of the respondents believed that they had moderate to good knowledge of the programming language JAVA. In the programming language Python, 7% of the respondents said they had good knowledge, 29% moderate to poor knowledge. All in all, however, those who have no knowledge at all of programming languages predominated with 73%. Other results are attached in the appendix C and D.

Figure 7.4. Most known Programming Languages (n=28)

The Teaching Concept

With the knowledge from 7.2 that 73% of the participants did not know any programming language at all, the aim was to introduce the participants to programming in the course Programming I and to bring together the participants with different knowledge. The educational science approach of combining case and practice orientation in connection with the development and realisation of problem-solving strategies was followed. The theoretical concept was developed with described or constructed examples with research-based learning in the practical phases (Siegling, Sybille, 2019). The competences to be taught in the course were specified and are presented in Table 7.1.

Table 7.1. Qualification goals theoretical content and competencies to be acquired

Timeline Teaching Concept

The teaching concept is divided into 2 phases. Phase 1 contains the theory from Table 7.1 and is designed as frontal teaching. For better understanding, contents were partly animated to enable the participants to follow processes step by step (e.g. step-by-step presentation of processes in programme development). The script was provided with links to the references so that students could look up programming words or other facts quicker during self-study. For the visual representation of internal memory processes, e.g. variable storage and pointers, the programme “Virtual C” by Dieter Pawelczak and Andrea Baumann was used, which was actually developed to detect plagiarism during the coding of a bachelor’s examination (Dieter Pawelczak, 2014). Phase 2 of the teaching concept focuses on the application and implementation of the content learned in phase 1. The conceptualisation of the proposed solutions was developed by pre-selected groups, in the present case two groups of 3 and eleven groups of 2, during the course and presented accordingly by one person of the respective group as a presentation after the given time of 2 hours. The other group participants were involved in the subsequent discussion. Finally, the concepts were implemented and tested on a robotic vehicle.  In order to create a productive environment, the tables were arranged in a rectangle-shape in phase 2 so that each of the students could observe the test procedures of the other course participants and a kind of test platform could be equipped in the middle with corresponding driving routes or objects depending on the task set. The tests were video documented accordingly for later evaluation.

Figure 7.5. Timeline Course Programming I – Day 1 to Day 5 divided in 2 Teaching Phases

Content of Teaching Suitcase

According to Nothacker’s studies ‘Low-cost Single-Board-Computers and Learning-Sets and the Relation to the “Digital” Didactic Goals’ (Jens Nothacker, Jens Nothacker 2021 – Low-cost Single-Board-Computers and Learning-Sets, 2021) and ‘A Mobile Suitcase for Informatic Teachers Related to the “Digital” Didactic Goals of the 21st Century’ (Jens Nothacker, 2021) the Teaching Suitcase used contained 9 Raspberry Pi 3+, 9 MicroSD cards with identical “Rasbian” operating systems, 9 Raspberry 3 Pi power supplies, 1 Raspberry Pi 4 power supply, Raspberry Pi keyboards, 3 rolls of 1cm wide black plastic tape, 1 10m Ethernet network cable, 1 multiple sockets with 3 connections, 1 power supply extension cable and 1 Robocar from the manufacturer Freenove (Freenove, 2021) with a Raspberry Pi 3 installed. The Robocar was equipped with a 5-megapixel camera (Raspberry Pi, 2021), 2 SG90 Micro Servos for vertical and horizontal control of the camera, an ultrasonic distance sensor, an optical line sensor, 8 RGB light emitting diodes, 4 linear motors and 2 high performance lithium-ion batteries. For possible network or internet failures, a FritzBox 7530  (AVM Deutschland, 2021) and a TP-Link 4G-LTE access point (TP-Link, 2021) were included in the case.

Figure 7.6. 70$ Robot car used in this study – Batteries not included. Picture Source: Manufacturer Freenove

Preparations before the course

The premises were equipped by the institute with tables and power connections at each table. The institute provided a wired internet connection without restrictions to the Raspberry Pi4 (RPi4), which is dedicated to network management and pre-installed with the RaspAP software (RaspAp, 2021), as a WLAN access point. The tables were movable and could be positioned differently in the room depending on the learning phase. The power supplies could be ported from table to table accordingly. The other 9 Raspberry Pi 3+ (RPI3+) were equipped with a microSD card and the latest Raspbian operating system. The individual devices were given unique device names Car1 – 9. All devices were pre-installed in ssh-mode to be able to access the individual devices from a terminal window. The robot vehicle was prepared for the first test run and the front right and rear left drive motors were swapped. This serves to ensure that the students have to correct at least one error in order to test their coding and have to rework the coding of the drive motors after the error has been detected in order to be able to successfully use their previously coded programs on the test machine.

Carrying out the teaching concept

Phase 1: Day 1 – 3
Phase 1 was conducted as planned as frontal teaching. In between, the lecture was loosened up with a questioning-developing teaching method with comprehension questions on the part of the lecturer, also to ensure learning progress. The students gladly accepted the intermediate questions and supplemented their specialist knowledge by passing on their knowledge and listening. Between the individual lecture days, the students made extensive use of their self-learning phase and asked questions as requested during the short recap in the first lecture hour on the following days. To answer the questions, the other students in the room were first given the opportunity to reveal their knowledge. If no answers were given by the students, the lecturer used the so-called ‘Socratic method’ to randomly select topic-oriented statements for discussion in order to check the learning success and the depth of the repetition of the self-learning phase. However, the short recap lasted a maximum of 10 minutes.

Phase 2: Day 4
In phase 2, the part of the lecture that was actually interesting for this study began with the division of the groups with the tasks 1-13 previously specified by the study leader. In order to break up socially pre-formed working groups, an allocation strategy was used that was based on the random principle. The students sorted themselves in ascending order according to the street names of their place of residence. The lecturer divided the groups into groups of 2 in order by writing down the corresponding name of the students and the corresponding task number, which was drawn from a pot holding the available tasks 1-13. This prevented previously formed groups from coming together again. In order to create knowledge groups that were as mixed as possible, the remaining students were assigned to the already formed groups according to the profiles “Professional” (P) or “Beginner” (B), which according to self-report did not correspond to the previously mentioned profiles, i.e. P to B and B to P. Attention was also paid to gender diversity. After the successful group building, the seating arrangement was arranged accordingly in a square. This allowed the newly found groups to sit next to their newly assigned fellow students. The new allocation is shown in Table 7.2.

Table 7.2. Task examples sheet after Group definition Phase 2 – Day 4

The students were provided with examples and programme libraries from the Robocar manufacturer for use. In addition, the open-source software OpenCV was made available for camera control. The students then began to develop the concept for their proposed solution based on the task. From then on, the lecturer acted as an observer and was available for questions, but without actively contributing to the solution. The last 2 lecture blocks were used to present the proposed solutions to the other students in a presentation and to exchange knowledge with them. The presentation time was limited to 10 minutes per group. The quality of the presentation was not included in the evaluation. The lecturer drew attention to the lack of quality in presentations. The presentations were handed in electronically to the lecturer for documentation and quality assurance. The students used their own notebooks to create the presentations.

Figure 7.7. Presentation of solution concepts, Phase2–Day4 (personal information has been anonymised)

Phase 2 Day 5

On day 5 of the event, the students were able to implement and test their solution concepts. The square table distribution was maintained so that the students could observe the demonstrations of their fellow students better in the afternoon, which took place within the square as planned. The groups determined the day before were kept. The RPI3+ devices including power supply and the MicroSD cards numbered according to groups were received by the students. The network group discovered right at the beginning that the dedicated RPi4 with the RaspAP software was not sufficient to guarantee Internet access for the 9 RPi 3+ and the Robocar. According to Group 13, the RPi4 with the RaspAP software cannot handle the number of 10 RaspberryPi devices plus the 28 notebooks they brought, for a total of 38 devices. Due to this situation, the dedicated RPi4 was replaced by a FritzBox 7530. From this point on, the network ran flawlessly.  As planned, the students had worked with the Robocar libraries and the OpenCV software for object recognition in their self-study phase. Since only one Robocar was available for the test run, the tasks were adapted to one vehicle. The students now began to implement the solution concepts created the day before. To implement the individual tasks, the students had code snippets provided with the Robocar to implement their part of the task. The group with the most network and programming knowledge (group 13) was entrusted with the supervision and setup of the network. The implementation phase lasted until 15:00 CET. After preparing the floor in the designated work area for the tests (laying out sheets of paper, attaching the guidelines with black tape), the groups started their tests. The demonstration of the results was done voluntarily in the order by placing the corresponding programme of the groups on the Robocar under the appropriate folders and starting it. The first attempts of Group9, Group2, Group7 and Group6 failed until one of the students discovered the cause of the error by lifting the vehicle and realising that the motors were probably controlled incorrectly. The students all corrected their programmes regarding the control error and started again in the next test rounds (Figure 7.8).

Figure 7.8. The student lifting the vehicle and realised that the motors were probably controlled incorrectly

At 15:40 CET, group 4 presented an object detection of a rectangle with the software, which was outlined in blue when detected (Figure 7.9).

Figure 7.9. Group 4 shows detection of a rectangle object using OpenCV and Phyton on a Laptop

At 16:31 CET, the first successes were recorded (Figure 7.10).

Figure 7.10. Group 1 shows distance control to an object

Between the session the students had to repair the test platform from sheets of paper (Figure 7.11).

Figure 7.11. The students repairing the test platform from sheets of paper

The car of Group 6 drove on the line with crossed circles after the group had corrected errors in motor contro l section (Figure 7.12).

Figure 7.12. Group 6 – shows the car is driving on the line with crossed circles after correcting errors in motor control section.

16:46 CET – Accidents could also not be ruled out (Figure 7.13).

Figure 7.13. Group 9 – Avoiding objects does not seem to have worked very well yet.

Analysing session from different views

In the following table, the most important processes of this event in terms of theory, practice and environment were assessed from the point of view of the different parties involved and classified in tabular form as an advantage or disadvantage. The processes were rated as advantage (+), disadvantage (-), and both advantage and disadvantage or don’t matter (~). The slash (/) represents for the conjunction “or”.

Table 7.3. Evaluate the event carried out from the point of view of the parties involved.

Conclusion and Outlook

The aim of this study was to answer the questions of what a teaching concept must look like in order to be able to use a mobile teaching case for computer science teaching efficiently and what advantages and disadvantages result for the institutions or teaching staff. The study was conducted at a university in a bachelor’s course of application computer scientists in the first semester. For this purpose, after a knowledge survey, the qualification level of the participants in various areas of computer science was determined through a combination of quantitative and qualitative analysis methods. In this study, the focus was particularly on programming languages and network knowledge. The analysis of the survey showed that about 73% of the participants had no or poor knowledge of programming languages, although the knowledge should have shown different results based on the curricula of the upper secondary schools in the countries of education. Less than 30% of the participants had good to above-average knowledge of the programming language JAVA. The knowledge of the programming languages C/C++ and Python was about 30% of the participants and ranged from moderate to poor. As a result, a two-phase teaching concept was developed, which pursued the goal of equalising the knowledge levels of the participants by combining the teaching of basic theory and subsequent practice, taking into account the curricular guidelines of the institute for deepening and developing the competences to be acquired. This was achieved through a combination of random assignment methods and subsequent correction by the lecturer according to assessments resulting from the theory part. Skills such as troubleshooting or debugging were actively provoked by the lecturer during the configuration of the hardware, from which unforeseen situations arose for the participants, even for those with deeper experience. However, this enabled the lecturer to promote and assess the participants’ problem-solving skills. From the point of view of the participants who described themselves as “professionals”, however, this process was described as unfair, they felt deceived and showed concerns about their previous assessment grade. Others referred to this as the “cold water method” and expected more sheltered, guided rather than experimental exploratory teaching, which is more in line with the upper secondary school approach. However, the author believes that the event was very positive in terms of the learning outcomes to be achieved. The students were able to learn and deepen their theoretical knowledge in phase 1 and then immediately apply it in phase 2. The students were encouraged to acquire and deepen the methods required in the curriculum. The students who already had programming experience were also challenged. By breaking up previously formed groups and reassigning them, expert groups were avoided, and an even distribution of the existing expert knowledge was achieved. The students worked diligently to solve the tasks and showed the stamina required in computer science. By using prefabricated code snippets, which however required adaptation, even those who described themselves as “beginners” were given the opportunity to have a sense of achievement after the “dry” theoretical phase and to make corresponding progress in the course, which was the prerequisite for the next course, since they inevitably already had to deal with the topic of object-oriented programming in the first approaches.

From the institutes’ point of view, using the mobile Teaching Suitcase for computer science teachers avoided significant deployment costs in the form of screens, computers, software and network equipment such as switches and internal cabling. This also relieved the support team of the institute’s IT department, which thus had time to spend on other support activities and only on enabling an unmanaged internet line. The lecturer was able to fall back on an expandable environment he was familiar with, thus minimising downtime and costs. The preparation times were kept within the usual limits for a group of up to 30 participants, and the costs for the teaching suitcase were kept low by using a Robocar for the start. Keeping the FritzBox on standby as a contingency plan has also proved useful. The provision of the 4G LTE router was not necessary for this event but should be taken into account by every lecturer and possibly included in the teaching suitcase as standard. A line with the highest possible data rate and unlimited data volume with calculable costs is recommended here. A commercially available smartphone that acts as a hotspot, preferably with 5G and unlimited data usage, would also be conceivable as an equivalent.

The fact that students publicly offered their tasks for solution in a forum was not intended. The deliberate disturbance of fellow students by taking over the control of the vehicle during the test phase disturbed the analysis. Unfortunately, this was observed in the case of one participant who described himself as a “professional” and was still young. Here, a few students should work a little on themselves for their own benefit and perhaps remember some rules of etiquette, which is indispensable for a cooperative collaboration in a constantly developing society. This is the only way we can all develop. What the author found great was the solutions the teams came up with in this short time and the fun we had while conducting the test rounds.

For the future, the author suggests extending the teaching concept to other courses (e.g. computer science for business studies). Since the students usually have their own notebook, it would definitely be a desirable approach. If this is not the case, the provision is limited to screens and possibly USB keyboards, which are usually available in large numbers at the institutes. However, if this is not the case either, a solution with a Raspberry Pi 400 and plug-in displays should be preferred. Then you are self-sufficient in any case. The further development of this concept in the form of station learning is also conceivable for more advanced courses in computer science. The author has in mind a mobile laboratory for computer science lessons. It would also be conceivable to control the vehicles via the Internet with simulation software, so that programmes could also be tested in times of a pandemic.

Acknowledgment

The author would like to thank Prof. Dr. Seon-Su Kim of the DHBW and his team in particular for their openness and willingness to allow me to carry out the concept on his campus at the castle in Bad Mergentheim. Thanks you, for the warm welcome I received from this team of professors. Thank you, also to the IT department, which organised the problem-free activation of an Internet connection, and many thanks to all the other participants whom I was able to get to know during the event. Thank you, also for the criticism. Thank you, to all those involved, whom I have not explicitly named here.