Adjusting the ChildProgramming Methodology to Educational Robotics Teaching and Debugging

Abstract

In 2013, the ChildProgramming methodology was presented as a model for teaching programming to groups of children between 10 and 12 years old, applying collaborative, playful, and agile development strategies. Different projects have been developed at the undergraduate and graduate levels at the Universidad del Cauca, where this methodology has been applied in case studies that have allowed its validation and adjustment, making contributions to the conceptual model (abstraction, transactive memory, gender, and gamification). In this article, a general review of the evolution of the methodology is conducted, and two new approaches that enrich the ChildProgramming methodology, the application of debugging practices, and the inclusion of educational robotics, are presented. The objectives, conceptual model, proposed practices, and the conclusions or results obtained in the validation process of these new elements, carried out in a real work environment applying the case study methodology, are presented. Likewise, the future of the methodology is presented in terms of work in progress and proposals for future work.

1. Introduction

The concept of “computational thinking” recovered by Jeannette Wing in 2006 [1] has gained widespread adoption in many countries, leading to its incorporation into educational curricula [2,3,4,5]. Simultaneously, the use of educational robotics has been increasing, with teams of children developing increasingly sophisticated products that can be evaluated based on the quality of the application that has led to incorporation of debugging practices into their projects. Children now have the ability to consider customer satisfaction, cost reduction, and resource optimization [6,7]. This shift toward problem-solving through computational thinking in STEM educational settings fosters innovation in the classroom. The act of modeling artifacts within the fields of electronics and robotics education captivates children, motivating them to devise solutions to real-world problems beyond mere data analysis, which often remains abstract to them [8].

The ChildProgramming method proposed by [9] aims to cultivate the thinking skills necessary for software design through playful activities, teamwork, and communication. This approach has undergone refinements over time, influenced by contributions from various undergraduate and graduate work. It has evolved from its initial version, through the identification of abstraction mechanisms within work groups [10], gamification [11], the recognition of work by gender among children [12], and the study of transactive memory in the execution of teamwork [13,14].

Although the ChildProgramming method intends that the work teams present the mission accomplished at the end, the developments in software platforms such as Scratch still maintain the intangibility of the product, even if a child is manipulating the keyboard or the mouse. Educational robotics seeks to encourage the participation of children in technology training models. In this training process, children encounter situations that represent “system failures”, which they must know how to identify and solve. The teamwork methodology allows children to understand the advantages of recognizing errors and seeking solutions. The central conclusions of this work in incorporating debugging and educational robotics in ChP focus on identifying these new practices as a good measure to improve quality. It not only involves children debugging their programs but also testing their own creations, which allows their deliverables to be of better quality. This, in turn, improves the performance of work teams. Another significant contribution of educational robotics to the development of computational thinking lies in its ability to involve the use of computers and the design, construction, and operation of robots. It effectively links abstraction and reality in a concrete way, facilitating the transition from the abstract to the tangible and increasing motivation to learn this type of knowledge. In this paper, we present the conceptual basis and findings of applying the use case strategy in the two research processes, seeking to resolve the following questions:

• What are the computational thinking strategies and scratch resources that children between 10 and 12 years old from the industrial technical school use to refine their projects?
• What are the differences in the quality component between teams working with ChildDebugging and teams working with ChildProgramming?
• By including educational robotics in the context of ChildProgramming as a tool for the development of computational thinking, is there a significant increase in motivation in CT development?
• Is ChildProgramming with ER (Educational Robotics) an effective guide for the appropriation of computational thinking development concepts by the children participating in the experiment?

2. Background

2.1. ChildProgramming

ChildProgramming [9] is a collaborative work methodology that has been validated in school environments. The work has focused on groups of children between 10 and 12 years of age. The public educational institution called “Institución Educativa Técnico Industrial de Popayán”, located in Colombia, has been the site of the case studies that have validated the ChildProgramming model in all its versions and complements since its initial version. This methodological approach was created from the belief that, despite the lack of technological resources, all children, regardless of their social or economic position, are capable of dealing with the issue of information technology. The notion of long-term human capital improvement in areas related to software engineering arises. The application of some elements of agile development processes in this phase allows groups of children to create software solutions through cooperation and play. Figure 1 shows the conceptual scheme of the ChildProgramming approach.

The underlying principles of ChildProgramming (ChP) encompass the consideration of various factors, including strategy, cognition, conceptualization, originality, cognitive growth, and both individual and group conduct. The method incorporates a blend of playful, collaborative, and flexible approaches, where pedagogical techniques are devised and implemented with a focus on teamwork, experiential learning, innovation, experimentation, and task organization. Figure 2. shows the phases of the method. Each of these three phases has a different purpose. The pre-game phase aims to establish the mission (fulfill the requirements) in a comprehensive manner. It involves providing detailed information to each team member, making sure they are familiar with the objectives and goals of each mission. In addition, they must gather the materials needed to carry it out successfully and assign tasks while organizing the group’s responsibilities. This preparation allows the transition to the next phase.

During the game phase, the main aim is to advance the mission and ultimately present a proposed solution at the end of each round. These rounds are iterative and require teams to progress through specific stages: planning, implementation, strategy review, and analysis as they work to solve the problem.

In the post-game phase, teams present their completed mission, which must meet the requirements outlined during the initial activity briefing. The teacher evaluates the team’s work based on the objectives established during the first phase.

Besides these elements, there are roles, concepts, and practices that encompass more specific components. Their general definitions are as follows:

• Roles: These are the individuals who take part in the process during class sessions and additional work sessions. The roles include the teacher, team leader, and work team as well as researchers or external observers.
• Concepts: These are integral to the development of activities and encompass cognitive, collaborative, and agile aspects.
• Practices: The work teams implement this crucial component, which further divides into three parts with distinct behaviors.
• Collaborative Component: This entails accepting the conditions necessary for activity development, engaging in team activities, and fostering a commitment to work collectively.
• Cognitive Component: This refers to adhering to the rules of the game, seeking clarification for any unclear aspects, and ensuring a comprehensive understanding of the activity’s topic.
• Agile Component: This involves partnering with a team member, effectively carrying out tasks, using the entire workspace with the team to enhance learning, and continuously improving the work’s efficiency.

2.2. ChildProgramming Methodology Evolution

As presented in introducing this article, since the presentation of ChildProgramming in 2013, different initiatives have been developed to complement the method and contribute to the improvement of the practices defined in it; these contributions are presented below intending to show how ChildProgramming is a unique method upon which the complements contribute particular ideas and processes. The objectives of each of these improvements and their contribution to the method’s conceptual and architectural model aspects are shown below. We consider it relevant to clarify the validation of each of the proposals.

• Identification of abstraction mechanisms, ChildProgramming-A [10]: It focused on defining and applying an incremental method that facilitates the analysis and design in the development of software in teams of children of school age between 10 and 13 years. Based on the application of shared mental models as a basis for the organization, planning, and coordination of development tasks. Apply a refinement of the proposed practices in ChildProgramming, focusing on the development of computational thinking, from the application of the mechanisms of abstraction, incremental missions, and shared thinking. The conceptual model of ChildProgramming is updated to include the refinement of the ChildElement class, with which the abstraction mechanisms identified in the practices with groups of children are associated.

Results:

• The incrementalism of the exercises promotes the assimilation of the fundamental computing principles; similarly, incorporating an example inside the guide provides a sense of relaxation in the team of children, and the tasks are successfully completed.
• Following the use of class practices that contain guidance examples, children discover and employ abstraction processes, such as generalization. This abstraction mechanism becomes an essential input so that they can later deduce concepts of abstraction, such as decomposition, while taking care to limit the use of guiding examples because of the possibility that this will direct the children in a solution without giving rise to creativity.
• When teams organized their work using shared mental models, they showed higher order and productivity than those that did not use this knowledge-sharing strategy. The ChildProgramming model includes enough structures to find the new abstraction mechanism ideas; the way they define the practices leads to the use of certain unique description slots. We describe abstraction practices using this new descriptor. They are activities in which collaboration employs a template to document the evolution of a solution; these templates include three columns (What am I going to do–What am I doing–What did I finish), and each team member must record and complete their assignment, which they set.

2.

ChildProgramming-G [11]: It aims to extend the ChildProgramming paradigm by introducing game features and dynamics that allow improving the performance of work teams in terms of quality, productivity, and behavior. Figure 3 shows the conceptual model of ChildProgramming-G. To apply gamification to the method, they add a package completely without changing the original structure. A GElement is defined that extends from ChildElement, and new elements are created by specialization from this concept so that each GElement is implemented within an independent package that can be managed as an extension package.

Results:

• Gamification improves work team effectiveness by encouraging learning and active engagement of children as well as increasing characteristics such as socializing, teamwork, and continuous development.
• The instructor is critical to the process because he or she is the one who must organize and oversee team performance from the start inside a gamified environment that he or she must construct.

ChildProgramming-Gender [12]: They provide particular approaches aimed at taking gender diversity and inclusion into account when integrating groups of boys and girls in the creation of computer programming activities. This study’s validation intended to shift interest in computer issues away from the gender stereotypes prevalent in society. Figure 4 shows the conceptual model of ChildProgramming-Gender where the practices include a new element (PracticeGender), and the gender dimensions are associated with ChildElement because it contains specific information related to the theme of inclusion and diversity, and these become input for the teacher to apply during the three phases of ChildProgramming.

Results:

• Teachers are the ones who aim to comprehend and evaluate gender-related issues, such as sexist behaviors, student interest analysis, and equality advocacy.
• Activities, surveys, and references to didactic material have been included in the practices in order to eradicate gender preconceptions in the classroom.
• When gender features are added, the team’s performance improves in areas such as productivity, quality, and conduct. The programming principles were applied to the school setting, with boys and girls keeping attention and stimulating involvement in the creation of the activities.

3.

ChildProgramming Transactive Memory GTM [13]: It presents several practices that are adjusted so that children’s teams apply transactional memory as an exercise in planning and developing activities. We identified the components that should be taken into account to develop transactional memory systems in group work, measuring the effectiveness of this new approach for ChildProgramming was carried out taking into account three aspects (specialization, credibility, and coordination). Figure 5 shows the contribution that has been proposed for the conceptual model of ChildProgramming, shows only the area included in the new entities that are proposed, in this case, the ChildProgramming-G model is taken as reference.

Results:

• It was evident that the contribution to the behavior of children allowed us to establish and recognize that there may be thematic experts that influence the planning and development of tasks.
• Proper collaboration and teamwork cause children to struggle to achieve the reward, allowing for greater efficiency in the solution.
• The practices include all information regarding practices that enable the development of the transactive memory system within the ChildProgramming-G process, facilitating expert training. ElementSMT consists of a name and a description that will allow describing the transactive memory elements that are associated with the PracticeSMT such elements are the basis for the development of the proposed practices.

3. New Proposals for the ChildProgramming Method

The new components of the ChildProgramming method integrate a computational thinking skill such as debugging with a computational thinking learning and development strategy such as educational robotics. In the context of programming, the concept of total quality, which involves testing and debugging programs, is fundamental. Not having a clear and universal way to solve these errors has been a problem [15,16], considering that it has been difficult to find an adequate teaching method for all students, which generates frustration and demotivation in them to learn to program. One of these strategies is the incorporation of educational robotics [17,18], which suggests implementing the development of computational thinking through mathematics and robotics, and also that, together with robotics, games can be designed. The interdisciplinary work offered by educational robotics requires constant study [19], taking advantage of the relationship it has with the development of computational thinking [20], which implies organizing new forms of collaborative work in the classroom. Educational robotics as part of STEM education facilitates active learning and promotes reasoning, critical thinking, and motivation [21,22]. Below, we present these two proposals that seek to provide a solution to the problems outlined above.

3.1. ChildDebugging

Debugging in ChP has been packaged as an extension called ChildDebugging. This extension is mainly located in the cognitive dimension within ChP, although it alters some points of the ChP development cycle. The team of children needs to make an effort to understand, analyze, and appropriately respond to situations present in the tasks that require their logical reasoning, planning, and synthesis because debugging works on the concepts of computational thinking during program correction, making the cognitive dimension key.

Figure 6 shows the conceptual architecture of the new complete ChildDebugging model, showing the packages already included in ChildProgramming and the new extension in the cognitive dimension that includes the concepts, practices, strategies, and debugging resources. In addition to this, it includes the ChildProgramming support tool package, which is basically a bug repository.

ChildDebugging as a process follows the same life cycle as ChP, which is organized in three phases (pre-game, game, and post-game) and development rounds. However, ChildDebugging introduces the following extensions: The process adds to the pre-game and post-game phases, the debugging rounds as a global strategy that seeks to smoothen the process of incorporating children into ChP and where it is sought that children assimilate concepts of computational thinking through program debugging. The process links debugging practices to the activity of applying strategy within all rounds of the game phase in ChP.

Before defining the strategies and resources that will lead to the creation of ChildDebugging practices, it is important to keep in mind that a series of steps must be followed for the resolution of errors that may occur in any type of system. These steps are based on the simplified model of [23]. This model is complemented by the one proposed by [24] that defines four steps for optimal debugging, among which are locating the bug, classifying it, understanding it, and repairing it. Once each of the strategies has been defined, a decision is made on how to proceed with the debugging process.

Table 1. Classification of strategies in the debugging process.

Strategy	Locate the Bug	Understanding the Bug	Fix the Bug
Code reduction (sub-strategy)	X
Analysis: step by step		X
Brute force, analysis, and forward reasoning	X	X
Backward reasoning	X	X
Analyzing casual reasoning	X	X
Impression function	X
Error handling	X
Reproduce bug		X
Trial and error			X
By example			X

shows the classification of the strategies according to the steps within the debugging process, that is to say, in which part of the process each one of these can be located, in order to structure the three main strategies that will finally be incorporated into the debugging practices.

Below,

Table 2. Locate the bug strategy.

Name of the Strategy	Locate the Bug
Goal	To find the cause of the bug
Description	This strategy follows a series of steps in order to locate the bug.
Action plan	Observe the parts inside the program; Choose the part to work on: the first one is the one that makes the bug visible, and then: Observe the execution of the program; Identify the problem with respect to the expected behavior; Analyze each line of code to understand the execution and any abnormality; Identify the point in the code that causes the bug; Reason about the bug; Record the bug found.
Resources	Step by step, watch point, brute force, print function, break point
Responsible	Debugger Support Web Tool Bug Box
Justification	It is the strategy used in the first part of the whole debugging process since it is to locate the bug in order to understand and fix it.

,

Table 3. Understanding the bug.

Name of the Strategy	Understanding the Bug
Goal	To understand the cause of the failure
Description	This strategy receives the report of the bug found and with this follows a series of steps to understand the bug.
Action plan	Read bug report; Reproduce error to understand what is wrong with the bug; Analyze the bug in detail: what is executed before, during, and after the bug; Test step by step the code lines around the bug. Breakpoint and watchpoint resources can be used; Complete bug report about what causes the malfunction.
Resources	Step by weight, brute force, print function, breakpoint, watchpoint
Responsible	Debuggers
Justification	Once the bug has been located, this strategy serves to understand and analyze in detail its operation in order to solve it later.

and

Table 4. Fix the bug.

Name of the Strategy	Repair a Bug
Goal	Repair a bug or bugs found in the program
Description	This strategy receives the report of the bug found, the analysis about its malfunction and with this follows a series of steps to repair the bug.
Action plan	Receive, read, and understand the report of the bug and its operation; Analyze what changes should be executed to solve the problem encountered; Modify the parts of the code where the bug is found based on the identified malfunction; Verify that the bug was eliminated by trying to reproduce the bug; If the bug persists, try another solution or use one of the other two strategies to re-localize the bug or extend the understanding of the already localized bug; If the bug is eliminated, test to verify that the bug elimination does not generate new bugs. In case of new bugs, they should be dealt using the bug localization strategy; Repeat until all bugs are eliminated.
Resources	Brute force, print function, step by step
Responsible	Debuggers
Justification	After locating and understanding the bug, you must eliminate it according to the knowledge you have and you must test recursively until you verify that there are no more bugs.

showcase the strategies incorporated in ChildDebugging. These strategies are designed to help locate, understand, and fix bugs. A strategy can be described as a plan to accomplish specific objectives under uncertain conditions. It involves setting goals, determining the necessary actions to achieve those goals, and utilizing available resources to execute those actions. In the context of ChildDebugging, a strategy refers to a set of rules or steps that children can employ to identify, comprehend, and address bugs within a program. Essentially, it serves as a roadmap for the team of children to effectively tackle bug-related challenges.

The web tool called Bug Box uses the mechanics and dynamics chosen and analyzed in the previous case studies to manage the bugs and the applications developed by the children. In case study 1, the bugs were recorded on paper. After case study 2, where the debugging practices and strategies were implemented, a web support tool was created to help increase motivation to learn, apply the debugging practices and strategies, and engage in activities related to Scratch and software development. This tool has two roles: The role of the administrator, who is in charge of managing the applications, and each application manages the bugs, and it also reports the number of bugs solved or not solved; In the student role, it is possible to access one of the registered applications and register bugs.

3.2. ChildProgramming + Educational Robotics (ER)

Educational robots can be seen as another step in the evolution of educational technology. Much of the application of robotic technology in education has focused on supporting the teaching of closely related areas, such as robot construction and programming [25]. However, robotics has a potential impact on learning in STEM areas [25], on cognitive development, and also on the development of research skills, creative thinking, decision-making, problem-solving, communication, and teamwork skills [26], all of which are very much in tune with the guidelines of computational thinking. Accordingly, the Japan Robotics Association, the United Nations Economic Commission, and the International Federation of Robotics have evidenced a recent and considerable growth in the use of robots for educational purposes and have anticipated that this trend will continue for years to come [25,27]. The many different robotic kits that have emerged since the 2000s (LEGO Mindstorms RCX, NXT, EV3, WeDo, Arduino, mBlock, KOBI, Makey Makey, Raspberry Pi, PicoBoard, Beagleboard, Crickets, Bee-bot, Cubetto, etc.), with improved and increasingly user-friendly designs, have paved the way for the popularization of robotics among students of all ages [26].

It cannot be disputed that educational robotics is increasingly present in educational centers around the world [25,26], but, despite its growing use, there is no common concept of what it represents [19], citing other authors, say, for example, that ER is a tool at the service of learning that allows practicing 21st century skills; or, in a more elaborate way, that it is a learning context that promotes a set of skills linked to creativity, design, construction, programming, and dissemination of own creations, first mental and then physical, built with different materials and technological resources, which can be programmed and controlled from a computer or mobile device. There is agreement, however, that the value of ER is not in teaching robotics to students but in taking advantage of its multidisciplinary nature for the construction of a technological object that has a specific purpose and that develops key skills for the students of the 21st century [19], skills among which, of course, computational thinking stands out since, when we talk about programming and robotics, we are inherently talking about CT. Retracing the steps of RE, we can go back to Papert, who gave birth to educational robots when he created his Turtle, designed as a real device that children could control with programs developed by themselves in LOGO, a computer language created by Papert himself [20,28].

The main theories behind ER are constructivism and constructionism [26,28,29]. Piaget argued that the manipulation of artifacts is key for children to construct their knowledge, to which Papert added the idea that this construction becomes especially effective in a context in which the learner is consciously involved in the construction of a public entity, whether it is a castle on the beach or a technological artifact [26]. That is why, by constituting something tangible and as mental development starts from concrete objects rather than the development of abstract reasoning, RE is not only relevant but also appropriate [29]. When engaged with RE, children become motivated and participate enthusiastically in projects, achieving learning goals and/or developing new skills [19,26]. Finally, Benitti [25] points towards the use of robotics as a tool for the development of thinking skills, problem-solving, and teamwork as it is an area in which the results are inaccurate, making necessary the development of evaluation tools on the matter, coinciding with [30] in their aforementioned study. Another finding highlighted by Bennitti is that, in the experimental designs used most frequently, the participants were not randomly assigned, and in 40% of the cases, a control group was not used. He infers, therefore, that there is a clear need for more studies involving a good experimental design and more significant samples.

ChildProgramming-ER, as an extension of ChP, makes use of educational robotics as a tool for motivation and participation in the development of specific PC skills in children. To achieve its objective, this extension provides a set of concrete guidelines for the use of aspects of educational robotics during activities aimed at the development of computational thinking in children between 10 and 12 years old. Although, in general terms, the proposed extension does not rely on a particular programming language or on any of the existing commercial educational robotic kits, it was evaluated in the context of the Scratch-based mBlock visual programming language and the mBot Ranger robotic kit, both from the manufacturer Makeblock.

The ChildProgramming-ER extension, as shown in Figure 7, is organized into four methodological packages, which are described below:

• Basic concepts that integrate computational thinking with educational robotics. This package describes the basic concepts of computational thinking and robotics that both the teacher and the students must know to understand the development of the training sessions.
• CT-ER Practices: Three types of practices are described that seek to use educational robotics as a tool for the development of computational thinking:
  • Educational Practices: they focus on the organization of working groups.
  • Practices for the development of computational thinking in the context of educational robotics: These practices allow the integration of computational thinking concepts with educational robotics applications.
  • Practices for the Evaluation of Computational Thinking: The objective of these practices is to evaluate and verify the assimilation of the concepts of computational thinking.
• ChildProgramming-ER practical guide: This guide has a series of well-defined sessions to guide a robotics course, following the ChildProgramming model.
• Lessons learned: These recommendations are proposed to conduct a session or develop a robotics course for children.

This methodological package allows the teacher, called an instructor or professor, and the students to integrate in a practical way the concepts of computational thinking and educational robotics, improving aspects such as:

• Collaborative work is the practice of organizing activities so that all members of the group work actively toward a common goal;
• The strategies put forward by the working groups when seeking a solution to the missions proposed in child programming;
• The evaluation of the theoretical concepts transmitted during the training sessions.

The ChildProgramming-RE package of practices has been divided into three sub-packages: educational practices, practices for the development of computational thinking in the context of RE, and practices for the evaluation of computational thinking. Each of the practices in these sub-packages is described by means of a structure, as a template, which corresponds to

Table 5. Organization of the work plan.

Work Plan Organization Practice
Description: Organize and plan the distribution of the work of the members of each of the teams during the development of the missions.
Addressed to: Teachers or instructors	Context: During a session of an educational robotics course.
Activities to be performed:
Make a list of the roles to be performed (Analyst, Programmer, Debugger, Algorithm Developer); Make a list of tasks and assign them to team members according to their role; Sequence the tasks and assign a time to perform them; Make a checklist of completed and pending tasks.
Entry requirements:	Expected results:
People participating in the robotics course: The total group of students and the teacher (teacher or instructor of the robotics course); To have an adequate work space and have the necessary materials for the development of the mission.	Active participation of each member of the group in the fulfillment of the missions; Optimal distribution of tasks; No one person is burdened with the work.

.

The following practices propose activities that allow the development of computational thinking in children’s programming missions with educational robotics applications and are recorded in the template shown in the table above:

• Fundamental Decomposition and Incrementality Practice;
• Error-Based Learning Practice;
• Practice of computational thinking development through educational robotics problem-solving.

These practices facilitate the assessment of concepts, whether they are previously acquired or newly learned, and provide the essential information needed to enhance session guidance and planning. These practices include the administration of a pre-test (refer to

Table 6. Pre-test.

Pre-Test
Description: It is an evaluation that is conducted at the beginning of a training session or at the beginning of a course (either educational robotics or programming), in order to know what previous knowledge you have of the topics to be developed in the training sessions.
Addressed to: Teachers or instructors	Context: In an educational robotics course or a programming course for 10 to 12 year olds.
Activities to be performed:
It is recommended to apply this test before starting the first training session. In the first class session apply a written test, either multiple-choice or open-ended questions; Explain to the student that there are no right or wrong questions, it is only for informational purposes.
Entry requirements:	Expected results:
Written or oral test with questions on the concepts to be covered during the course.	Developmental level of the child’s computational thinking prior to initiating any related learning activities.

) and a post-test (refer to

Table 7. Post-test.

Post-Test
Description: Test or evaluation at the end of the course, in order to evaluate the concepts learned during the training sessions.
Addressed to: Teachers or instructors	Context: In an educational robotics course or a programming course for 10 to 12 year olds.
Activities to be performed:
These activities are recommended for the penultimate or last session. Apply a written test, either with multiple choice or open-ended questions, similar to those of the pretest; Explain to the student that there are no good or bad questions, it is only for informational purposes.
Entry requirements:	Expected results:
Written or oral test with questions related to the concepts covered during the course; Solutions to the proposed missions (programming code in blocks or working robot)	Level of development of the child’s computational thinking after completing all planned learning activities.

).

Table 8. Observation.

Observation
Description: Observation involves watching the work of the teams and, in addition, inquiring about the difficulties encountered in the development of the missions as well as listening to the solutions proposed to the projected problems.
Addressed to: Teachers or instructors	Context: In an educational robotics course or a programming course for 10 to 12 year olds.
Activities to be performed:
Take note of the reasons that generate nonconformity in each team; Continually ask students about their progress and, in some way, ask questions that allow them to identify if they are correctly applying the concepts previously explained; Separate, isolate and, if necessary, replace any material or essential component that is failing and, consequently, does not allow a good development of the mission.
Entry requirements:	Expected results:
Distribution of working groups. Teacher attentive to students’ work. Teacher’s activity plan; Observation diary to record some observed data, as proposed in [31].	Observation journal to identify problems, solutions, and the impact of observations on learning.

details the actions to be taken when applying the observation step, the objective of which is to observe the work of the teams and inquire about the difficulties encountered in the development of the missions as well as to listen to the solutions proposed to the problems raised.

Below, we present the activities suggested in the ChP-RE guide for the development of computational thinking in the context of educational robotics, specifying their purpose and the description of each work session carried out with the children.

• Session 1:
  • Activity: Pre-test.
    • Purpose: To understand students’ prior perceptions of robotics and computational thinking concepts.
    • Description: Gathering information from the students themselves, to get an idea of the prior knowledge that they have about robotics and computational thinking.
  • Activities: Identification of the characteristics of the robots and identification of computational thinking and its associated concepts.
    • Purpose: To know the concepts of robotics and computational thinking.
    • Description: First approach, in the form of an explanation, to the concepts of robotics and computational thinking.
  • Activity: Assembly and play with mBot.
    • Purpose: To familiarize students with the robot.
    • Description: Student contact with the robot. Students assemble the robot and play with it, while reinforcing robotics concepts.
  • Activity: Identification of the actuators on the mBot.
    • Purpose: To understand what actuators are and what their function is.
    • Description: Explanation of the different types of actuators on the robot, teaching the students with a brief explanation of operation and giving examples of situations in which they could be used.
• Session 2:
  • Activity: Abstraction and algorithms in everyday life.
    • Purpose: Understand the importance of abstraction and algorithms, and the construction of the latter.
    • Description: It is explained through examples to the students that abstraction and algorithms are often performed in daily life, unconsciously, and that it is convenient to apply it in a conscious and methodological way to many processes. They are asked to develop algorithms for school tasks or activities that they themselves propose, emphasizing the existence of more than one solution to the same problem.
  • Activity: Abstraction and design of algorithms as a preliminary step to coding and construction of code blocks involving actuators.
    • Purpose: To know the mBlock programming environment.
    • Description: First approach to the programming environment and development of a simple program that demonstrates how the programmed actions are reflected in the operation of the robot, with emphasis on the actuators (movement, lights, and sound). It is suggested to combine mandatory actions, which allow verifying that the robot does what the students order, with free actions that allow them to express themselves freely and make use of their creativity.
• Session 3:
  • Activity: Decomposition pattern recognition into complexes tasks.
    • Purpose: Understand the concepts of decomposition and pattern recognition.
    • Description: Students are explained through examples what decomposition and pattern recognition consist of and their usefulness in solving problems by reducing their complexity or by tackling totally or partially similar problems. They are asked to decompose common problems proposed by themselves and/or by the teacher.
  • Activity: Verification in mBlock of the status of the mBot’s infrared sensor.
    • Purpose: Learn how to operate the infrared sensor as a line follower.
    • Description: Explanation of the mBot’s infrared sensor, and its operation as a line follower, together with the mBlock commands that allow to know the information it delivers (its status).
  • Activity: Decomposition of the problem, solution algorithm, and line follower with the mBot.
    • Purpose: Learn to use Boolean operators and control structures.
    • Description: Creation of simple programs that allow the inclusion of Boolean operators and the statements of IF-ELSE or infrared sensor. Before starting with the coding, it is necessary that the students present and support the decomposition of the problem and a solution algorithm.
• Session 4:
  • Activity: Quiz.
    • Purpose: To evaluate the knowledge about the concepts of robotics and computational thinking.
    • Description: Recap of the meaning of computational thinking and the already worked concepts of abstraction, algorithms, decomposition, and pattern recognition.
  • Activity: Verification in mBlock of the status of the ultrasonic sensor of the mBot.
    • Purpose: Learn how to operate the infrared sensor as a line follower.
    • Description: Explanation of the ultrasonic sensor of the mBot, and its operation as an obstacle detector and distance meter, along with the mBlock commands allow to know the information it delivers.
  • Activity: Problem-solving with the application of computational thinking with robots.
    • Purpose: Putting computational thinking into practice and robot programming to solve a particular problem.
    • Description: Given a problem posed by the teacher, the students must, under the teacher’s guidance, assistance, and supervision, apply the concepts of computational thinking and robot programming to solve it.
• Session 5:
  • Activity: Final Challenge and Post-Test.
    • Purpose: Putting computational thinking into practice and programming robots to solve problems autonomously.
    • Description: Students must apply the concepts of computational thinking and robot programming to solve a problem posed by the teacher with minimal assistance.

4. Case Studies

4.1. ChildDebugging

CASE 1.

Objective: To identify the computational thinking strategies and Scratch resources for children between 10 and 12 years old that the IE Técnico Industrial de Popayán implicitly use to debug their programs and select those that can be incorporated into the ChildProgramming model.

Question: What computational thinking strategies and Scratch resources do the children between 10 and 12 years old from the IE Técnico Industrial de Popayán use to debug their projects?

Indicators: Percentage of use, level of effectiveness, level of efficiency, identified strategies, identified Scratch resources, types of errors, understanding of errors.

Data collection: Observation template, Scratch program, survey, log sheet.

CASE 2.

Objective: To analyze the differences in the quality component between teams working with ChildDebugging and teams working with ChildProgramming, among children from 8 to 10 years old from the IE Técnico Industrial de Popayán.

Question: What differences are observed in the quality component between teams working with ChildDebugging and teams working with ChildProgramming?

Indicators: Total quality, error density, debugging capacity, analysis value, analysis effectiveness, ease of error resolution.

Data collection: Field observation, survey, code, bug reports, audiovisual material.

4.2. Child + RE Programming

CASE 1.

Objective: To analyze the effect of incorporating educational robotics elements into the ChildProgramming model, with the purpose of evaluating its impact on motivation, participation, and appropriation of CT concepts from the perspective of the researchers in a technology course with students aged 10 to 12 years old.

Question: Does the inclusion of educational robotics in the context of ChildProgramming as a tool for the development of computational thinking result in a significant increase in motivation for CT development?

Indicators: Direct expression of motivation, direct expression of team participation, knowledge of computational thinking concepts (abstraction, algorithms, decomposition, pattern recognition, and programming).

Data collection: Pre-test, post-test, and observation protocol.

5. Results

5.1. ChildDebugging

The context in which the validation of this addition to the ChildProgramming model was performed was as follows:

Age of the participants: between 10 and 12 years old;

Grade of schooling: Seventh grade;

No. of participating students: 35;

Work sessions: 3;

Date: From 3–17 November 2017.

Evaluation instruments:

• Direct observation;
• Observation form;
• Debugging form;
• Survey;
• Video;
• Scratch applications.

When comparing the performance of the control group and the experimental group, the following results were obtained:

○

In terms of overall quality, the control group obtained 32% performance, while the experimental group obtained 72.22%;

○

As for the ability to debug, the control group performed 50%, while the experimental group performed 90%;

○

As for the analysis value, the control group obtained 61.4%, while the experimental group obtained 78%;

○

In terms of analysis effectiveness, the control group obtained 83.2%, and the experimental group obtained 96.6%.

Figure 8 illustrates the variation in performance results between the experimental and control groups when applying the debugging practices. These indicators provide an assessment of the impact of the debugging techniques on the control group, which did not use these practices. The following indicators were considered:

• Total quality: This indicator measures the percentage of overall mission quality. It is calculated by multiplying two ratios: the ratio of objectives met to the total number of mission objectives, and the ratio of errors corrected to errors found;
• Debugging ability: This indicator assesses the student’s ability to troubleshoot their applications. To calculate it, multiply the number of corrected errors by 100 and divide the result by the total number of encountered errors;
• Analysis value: This indicator reflects the number of analyzed bugs that have been successfully resolved. It is calculated by dividing the number of analyzed bugs by the number of identified bugs;
• Analysis efficiency: This indicator measures the efficiency of the failure analysis. To calculate it, divide the number of resolved bugs by the number of analyzed bugs.

Five signs of frustration that were noticeable in the groups are shown in Figure 9. As we can see, the control groups displayed the most frustration, worry, abandonment, and resignation symptoms. Out of the four signs that were presented in these two groups, these three were the most prevalent. In the five control groups, worry was the most prevalent indicator, followed by conversation, irritability, and resignation. Only two groups seriously considered giving up on the challenge. Only two groups out of the experimental ones present three signs as their work progresses, with one sign in common—worry—and the experimental groups showing a change in the frequency of signs of frustration compared to the control groups. The experimental groups all exhibit this symptom. In relation to the signs of abandonment, rage, and resignation, the sign-denominated discussion was barely present in any of the five groups. The instruction on how to correct mistakes aided in lowering the level of frustration and sense of failure.

5.2. ChildProgramming + RE

The context in which the validation of this addition to the ChildrenProgramming model was carried out was as follows:

Age of participants: between 10 and 12 years old;

Grade of schooling: Fifth grade;

No. of participating students: 6;

Work sessions: 4;

Date: 1–21 December 2021.

Evaluation instruments:

• Direct observation;
• Pre-test;
• Post-test;
• Use of the web application: Dr. Scratch: http://www.drscratch.org/, accessed on 5 December 2021.

Quantitative results on motivation, participation, and appropriation of computational thinking were obtained from direct measurements. Below, we present the observation criteria for each of them:

Motivation:

• Is motivated to overcome difficulties in performing tasks;
• Is motivated to understand errors in order to correct them.

Both the control group and the experimental group were motivated at the beginning of the work, and at the end of the work, they all felt very motivated by what they had performed.

Participation:

• Cooperates with other group members during activities in a positive way;
• Obeys the rules of behavior during the projects;
• Participates in group work;
• Helps peers solve problems.

Regarding teamwork, both groups expressed at the beginning of the work that they always or almost always liked to work that way. Both groups maintained this perception at the end of the work sessions.

Appropriation of computational thinking: the Dr. Scratch application was used to evaluate the projects in the post-test phase, and the results of the abstraction, flow control, and logical thinking skills were taken into account.

The results showed that at the beginning of the course, only half of the children said they had some knowledge of the concepts of programming and pattern recognition, but all of them did not know the concepts of algorithms, decomposition, abstraction, and computational thinking. The post-test results show an improvement in the appropriation of the other concepts of computational thinking.

6. Discussion

The implementation of debugging within the ChP model included quality practices that improved the outcome of the children’s teamwork, highlighting the importance of addressing problems and making programming exercises more tangible. The exploratory case study identified strategies and resources that children use when debugging their programming projects. In the confirmatory study, the application of these debugging strategies and resources resulted in evident improvements in overall quality outcomes. In the implementation of educational robotics, the exploratory study provided insights into the necessary conditions and specific details for the confirmatory experiment. It concluded that maintaining motivation relies on favorable working conditions and addressing robot failures promptly, as children can become demotivated when faced with technical issues. The children actively participate in the activities, and teamwork strengthens positive interpersonal relationships within the group. Furthermore, the children significantly grasped and appropriated the concepts of computational thinking, including decomposition, pattern recognition, and algorithmic thinking.

In terms of lessons learned, we can say that at the beginning of the robotics course, it is important that the teacher or instructor make a plan for each of the sessions to carry out the missions before proposing them to the students in order to: foresee possible failures of the physical parts, errors of the robotic system, etc.; plan and foresee the programming of the students; and know what elements are necessary for the fulfillment of the mission.

To achieve an integration of the development of computational thinking with educational robotics, it is important to make a theoretical account of the concepts of computational thinking so that it is easy for the student to relate the practical activity to its theoretical component.

The robot, in itself, is a distraction. It is recommended that teams only access it when they have presented and exposed an acceptable analysis (requiring abstraction and decomposition) and algorithm. To reduce the distraction, it is proposed that:

• Except in the first session, to avoid distractions, the use of screens other than those used for programming the device should be avoided, excluding, of course, those required by the instructor(s) for the development of the activity.
• The workspace should be sufficiently large, with a dedicated area for robot testing where two or more teams are likely to coincide at the same time.

When creating or designing the missions to be carried out in each training session, it is advisable to include those that involve assembling the robot, as this is one of the activities that most motivates the students, and, if possible, allow them to personalize it (for example, by giving it a name and decorations of their choice).

In terms of cost, the mBot Ranger is in the middle ground compared to other similar kits. It is a robot with an Arduino-based control unit, programmable with mBlock (based on Scratch) via Bluetooth connection. The mBot Ranger features a line tracking sensor, light sensors, a gyroscope, and actuators including motors, led lights, and a basic horn capable of playing variable-frequency tones.

7. Conclusions

The research concludes that incorporating debugging into ChP is beneficial for improving quality. Debugging and testing by children lead to better quality deliverables and improved team performance. The student analysis shows that ChildDebugging positively impacts the quality of results and the development of debugging skills. However, it does not affect the value or effectiveness of bug analysis compared to ChP.

Educational robotics, guided by the constructionist philosophy, facilitates learning by transferring experiences from robot interactions into transformative ideas. It effectively combines computer use with robot design, construction, and operation, bridging the gap between abstraction and reality. This fosters not only CT skills but also motivates children to solve meaningful problems, enhancing their interest, motivation, and skills in communication, collaboration, creativity, autonomy, and leadership.

Educational robotics alone does not directly impact student learning; it requires an appropriate educational philosophy, learning environment, and methodology. The proposed ChildProgramming-ER extension, structured in four methodological packages, integrates educational robotics into CT development for children aged 10–12. It provides concrete guidelines for using educational robotics in activities that promote computational thinking. The extension includes a practice guide for a robotics course based on the ChildProgramming methodology.

In the confirmatory experiment, we observed noticeable improvements in computational thinking skills, particularly those measured by Dr. Scratch, in both the experimental group (using ChildProgramming-RE) and the control group (using ChildProgramming). There were no significant differences in interest or motivation between the two groups. While there were no significant differences in the appropriation of computational thinking concepts related to algorithms and abstraction, the experimental group showed a stronger grasp of pattern recognition and computational thinking itself. Conversely, the control group performed better on the concept of decomposition. The experimental group also demonstrated the application of computational thinking concepts in activities such as designing, assembling, and manipulating the robot, despite difficulties in verbal expression. Further research is needed to evaluate computational thinking using the ChildProgramming methodology and validate its effectiveness in skill development.