Learning to Engineer: Integrating Robotics-Centred Project-Based Learning in Early Undergraduate Education

Abstract

Engineering programmes have been giving more weight to experiential learning, largely because many students still find it difficult to see how classroom theory connects to the work that engineers handle on the ground. With this in mind, a robotics-centred Project-based Learning (PBL) module was introduced to first-year general engineering students as part of the faculty’s engineering spine. The module asks students to design, build, and program small autonomous robots capable of navigating and competing in a set arena. Even a simple task of this kind draws together multiple strands of engineering. Students shift between sketching mechanical layouts, wiring basic circuits, writing code, testing prototypes, and negotiating the usual challenges that arise when several people share responsibility for the same piece of hardware. To explore how students learned through the module, a mixed-methods evaluation was carried out using survey responses alongside reflective pieces written by the students themselves. Certain patterns appeared repeatedly. Many students felt that their technical skills had grown, particularly in breaking down a messy problem into smaller, more workable components. Teamwork also surfaced as a prominent theme. Groups often had to sort out issues such as a robot veering off course due to a misaligned sensor or a block of code producing unpredictable behaviour. These issues were undoubtedly challenging for the students, but they also had a certain pedagogical flavour, with many students describing them as a source of frustration as well as a learning opportunity. Later iterations of the module may benefit from more targeted support at key stages. Despite the many challenges, robotics has been shown to be an attractive way for students to step into engineering practice. The project helped them build technical capability, but it also encouraged habits that matter just as much in real work, such as planning, communicating clearly, and returning to a problem until it behaves as expected. Taken together, the experience offers useful guidance for curriculum designers seeking to create early learning environments that feel authentic and manageable and for motivating students who are just beginning their engineering journey.

1. Introduction

University engineering programmes play an important role in preparing engineering students to become industry ready. Ideally, their university years should equip them with the relevant tools and competencies needed to become part of the engineering workforce (Brunhaver et al., 2018). However, traditional methods of teaching often emphasise theoretical foundations delivered through hand-holding approaches such as lectures, seminars, and tutorials; whilst these are sometimes necessary, especially for imparting important engineering theories, relying on them alone may not enable the development of the practical engineering, problem-solving, and teamwork skills that are essential to become a good engineer (Immerstein et al., 2019; Prince & Felder, 2006). Consequently, universities have to adopt new pedagogical methods alongside traditional teaching methods.

Experiential learning approaches, such as project-based learning (PBL) (Meng et al., 2023), problem-based learning (PrBL) (Hmelo-Silver, 2004), cooperative learning (Yang et al., 2024), active learning (Freeman et al., 2014), and design-based learning (DBL) (Oo et al., 2024), may be able to provide effective bridges between theoretical engineering concepts and real-world engineering applications (Asfani & Chen, 2025), the primary criticism of traditional teaching methods. These approaches commonly focus on hands-on work with realistic, albeit commonly smaller-scale, engineering problems (Asfani & Chen, 2025; Prince & Felder, 2006). For instance, PBL provides engineering students with relatively complex, real-world projects. These force students to self-learn interdisciplinary domains and apply diverse skills to solve a given problem, thereby strengthening their understanding of various domains and their interconnections, whilst also developing critical thinking, teamwork, and communication skills (Lavado-Anguera et al., 2024). Problem-based learning (PrBL) is almost similar to PBL, although it usually begins with an open-ended, real-world problem that students have to make sense of before they can even decide how to approach it (Meng et al., 2023). The emphasis falls less on producing a single “correct” answer and more on the process of thinking through different possibilities, which tends to bring out a certain creativity and a willingness to try ideas that may not work the first time. Cooperative learning takes a different angle. It focuses on small groups working toward shared goals, and the constant negotiation within these teams often does as much for students’ communication skills as any formal training (Yang et al., 2024). Active learning brings a different texture to the classroom. Rather than sitting through a sequence of explanations, students may suddenly be asked to track down the cause of a misbehaving simulation or take on a role in a brief scenario. These may reveal gaps in understanding that would otherwise never be thought of in a traditional learning method, thereby forcing students to fully digest their understanding of a topic (Freeman et al., 2014). DBL focuses on yet another angle by emphasising product development. Students are required to build a prototype, necessitating a trade-off between ideal designs and practical considerations. The iterative product development process, which considers what is to be created and the required materials, time, and tools, embodies the realities of engineering, where even the most elegant concepts must confront practical constraints (Oo et al., 2024).

Among the different approaches, PBL has been gaining popularity in engineering programmes. Its structured approach provides enough direction for students but still allows limited freedom for them to explore and test ideas that intersect with different technical domains (Meng et al., 2023; Lavado-Anguera et al., 2024). A well-designed PBL project allows students to be exposed to the complexity of engineering, where technical knowledge, real-world constraints, and unexpected problems often meet together (Hasan et al., 2024; de Dampierre et al., 2024).

PBL can appear in many forms, and this diversity hints at how easily it adapts to different corners of engineering. In a renewable energy project, for example, students might spend one week wiring a small proton-exchange membrane fuel cell and the next testing a basic wind turbine prototype, discovering along the way how theory behaves when transformed into hardware. Work of this kind blends electrical, mechanical, and chemical concepts in ways that are hard to achieve through lectures alone (Goodman et al., 2010; Desnita, 2017). Internet of Things (IoT) projects may involve programming, networking, and sensor technologies to develop smart IoT systems (Ratnayake et al., 2025; Fortoul-Diaz et al., 2021). Civil engineering projects, such as the design of a modest bridge, push students toward questions of materials, loads, and soil behaviour, each with its own set of constraints (Das, 2023). In biomedical engineering, students may attempt early versions of prosthetic components or wearable monitors, which inevitably forces them to consider how mechanical parts interact with the human body (Milani et al., 2019; Freudzon, 2022). Even fast-moving domains like UAVs, UGVs, USVs, and UUVs now fit comfortably within PBL setups, giving students a chance to work with control algorithms, sensor fusion, and embedded programming in a very hands-on way (Mesas-Carrascosa et al., 2019).

Robotics has become one of the more popular choices within this landscape (Copot et al., 2016; Bada et al., 2014; Coufal, 2022; Barradas et al., 2024). Part of the appeal comes from its sheer interdisciplinarity. A single project can require students to sketch a mechanical frame, wire up a motor driver, and then puzzle over a piece of code that refuses to behave. These projects may require students to design, build, and refine systems that operate autonomously by responding to their surroundings via sensors, actuators, and microprocessors. The work rarely proceeds smoothly; components fail, code loops misbehave, and sensors drift, which forces students to troubleshoot in ways that build both technical insight and patience. Because the robots react immediately to any changes students make, the impact of each decision becomes visible almost instantly, and this immediacy tends to hold their attention. The collaborative and competitive elements add a different kind of energy, with teams often required to divide tasks on the go, arguing over small design choices or quickly putting an alternative plan together when something just does not want to go according to plan. These mimic real engineering work, with the potential to develop the so-important soft skills, such as leadership, coordination, and the ability to remain composed under pressure, that cannot be developed through traditional teaching methods. Of course, robotics also has a natural appeal; it is very unusual to meet anybody who is not at least a little curious about a machine that moves because of code and components that they assembled themselves. These combinations make robotics a compelling project to bridge between theory and engineering practice, one that frequently sparks the kind of interest that keeps students experimenting after project completion (Bada et al., 2014).

Within the context of engineering education, learning outcomes of a robotics-based PBL may extend across multiple domains. However, in this study, the primary emphasis is put on technical skill development, including programming, electronics, and mechanical and system integration, as well as on the understanding and application of a structured system engineering process, including requirement definition, design development and selection, project planning, and iterative prototyping. Additionally, the robotics-based PBL may also allow the students to improve their all-important professional skills, particularly teamwork and communication. The outcome from the project may also affect their confidence and future interest in the engineering profession. Robotics-based PBL is well suited to this meshing of learning, with students required to integrate technical knowledge within a structured engineering process whilst operating under practical constraints.

Whilst competition-based and robotics-based PBL approaches have been increasingly implemented within engineering education, not many studies can be found in the literature, and even fewer have studied their implementation at the very beginning of an engineering programme on students who have limited prior technical exposure and little familiarity with the structured engineering processes. Naturally, early experiences during this transition period from college to university are very important and would influence how students engage with technical problem-solving and systems-level thinking in the engineering context.

The robotics-based PBL project discussed in this paper originates from the first of eight modules that comprise the engineering design spine shaping the engineering programme. Run during the first semester of the eight semester-long programme, the module introduces students to engineering practice through a structured systems engineering process, including requirement definition, concept development and selection, project planning, prototyping, testing, and competitive evaluation. Accordingly, this study examines how this robotics-based PBL affects students’ learning, from the skills and knowledge they acquire to their confidence and interest, with a broader aim of contributing to the ongoing discussions about experiential learning, particularly in engineering education.

2. Pedagogical Approach and Implementation

The robotics-based PBL project is a key component of the first-semester Engineering Design 1 module within the faculty’s broader engineering design spine and serves as the first real step into hands-on engineering for many of the students. It allows the students to move beyond theories into work that involves designing, building, testing, and then reiterating the process again, but within practical constraints. The competitive framework of the project introduces a fun element, encouraging students to think creatively and to work closely as a team.

The unique engineering design spine consists of a sequence of eight interconnected design modules distributed across the engineering programme, one in each semester. They are carefully structured to progressively develop competencies in systems engineering, design thinking, prototyping, and project management. Engineering Design 1 and Engineering Design 2 directly use robotics to introduce foundational technical and process-based skills, while subsequent modules extend these principles to increasingly complex and diverse engineering contexts, which are not necessarily robotic-based. The final two modules form the programme’s capstone projects, requiring students to integrate knowledge across domains within open-ended, system-level engineering problems. Whilst not all modules are explicitly robotics-focused, all stages of the spine emphasise a structured systems engineering approach, multidisciplinary collaboration, and iterative design, thereby reinforcing and building upon the competencies introduced in the early robotics-based projects. Whilst the engineering design spine, and hence the current module, has been run since the introduction of the programme in 2013, the present work represents the first systematic, survey-based study conducted to formally examine student learning outcomes from the first-semester robotics-based PBL module.

2.1. Robot Competition Framework

The competition requires teams of students to build autonomous robots capable of moving from friendly to enemy territories, before switching off two enemy target lights before their opponent. Each match pits two robots against one another, one starting from the black zone and the other from the white zone; a match ends when both enemy lights or both friendly lights are switched off or when the set time has elapsed. Success usually depends on a blend of technical skills and a strategy, and sometimes also luck.

Figure 1 shows the arena of the competition, which measures 4 ft by 8 ft and is divided into black and white territories that mark friendly and enemy territories. Robots begin in clearly marked starting positions and must retain information about their initial floor colour (as friendly territory) to navigate correctly into enemy territory during the match. A small maze sits at the centre, requiring teams to introduce either collision avoidance or detection into their robots. Navigation support from the friendly to enemy territories comes from a central light suspended about 0.75 m above the arena. Each territory has two target lights positioned roughly 15 cm above the floor; only one light is active at any given moment, with the second light activated once the first has been deactivated. Thus, the competition is a sequential challenge of moving from friendly to enemy territories, deactivating the first target light before moving to the second target light. To control for ambient lighting and ensure consistent sensor behaviour, the entire arena is enclosed with black curtains.

Figure 1. (a) The arena layout for the robotics competition, and (b) the detailed floor plan of the arena. The ‘×’ symbols indicate the robot starting positions, where each robot is initially placed with a random orientation at the beginning of the competition.

Teams are assigned either one of two robot types (Loganathan & Ahmad, 2023):

• Crawler-based robots: Prioritising stability on uneven terrain.
• Wheel-based robots: Optimised for speed and agility on smoother surfaces.

All teams build from the same Parallax BoE Bot kits, which keeps the baseline technology consistent while still allowing students to explore different design approaches. Through this setup, students begin to see for themselves how choices in locomotion affect performance, and how speed, stability, and control rarely align perfectly in a single design.

The competition is organised into two parallel round-robin leagues, one for each robot type. Teams compete within their own league before the strongest performers move on to knockout rounds, where they may face opponents using a different mobility system. Match duration reflects the character of the robots themselves: car-based robots run shorter three-minute rounds, while the slower but steadier crawler-based robots compete over five minutes. Table 1 presents the scoring scheme, where each robot has the potential to receive a score ranging from a maximum of 20 points to a penalty score of −5.

Table 1. Scoring breakdown and task-specific points.

Task	Points
Crossing to the enemy territory	5 points
Knocking out the first enemy target light	5 points
Knocking out the second enemy target light	10 points
Deactivating a friendly light	−2.5 points, +2.5 points to opponent

The scoring scheme encourages teams to think strategically within their robots’ limits. The round-robin league also allows teams to improve or adopt new strategies and improve their robots, mimicking the iterative cycles of an actual engineering project.

2.2. System Engineering Process

Teams are required to follow a structured systems engineering process, as shown in Figure 2. The system engineering process is an iterative process, beginning with defining the requirements, followed by concept development and selection, and, finally, prototype development, mimicking how real-world engineering problems are typically approached.

Figure 2. Simplified system engineering process adopted in the project (Abas et al., 2025).

• Defining Project Requirements

Teams begin by identifying the key requirements which must be accomplished by the robot to fulfil its mission, alongside desirable requirements, which would simply enhance performance. Full autonomy is one of the fixed conditions. Once a match starts, the robot must operate entirely on its programmed logic and sensor readings, without any human correction. Other typical requirements include the following:

• Navigating between zones by detecting floor colour and using navigation lights.
• Avoiding obstacles through collision detection.
• Sequentially deactivating enemy lights using light detection and sensor coordination.

Students distinguish between essential and optional features, aligning design decisions with performance goals.

2.

Concept Selection Using Developed Criteria and a Pugh Matrix

Once the requirements are established, teams set out a series of weighted criteria to help steer their design decisions. Mobility, sensor consistency, and power efficiency tend to appear near the top, although different teams place emphasis on different aspects depending on their design philosophy. The proposed concepts are then examined using a Pugh Matrix, allowing students to compare alternatives in a more organised and transparent way. Scoring may be performed as a group, where each rating is discussed and agreed upon, or individually, with the scores averaged to prevent any one voice from shaping the outcome too strongly. This approach encourages students to make evidence-based decisions.

3.

Project Planning and Gantt Chart

Once a particular design concept has been selected, teams move into the planning phase. Typically, this begins by breaking down the project into distinct and manageable tasks/sub-tasks, i.e., a work breakdown structure. A dependency graph then helps map out which tasks/sub-tasks need to precede the others; for instance, a circuit for detecting floor colour cannot be soldered on a perfboard until its circuit connection has been designed and tested on a breadboard. The Gantt chart brings everything together by arranging the tasks/sub-tasks along a timeline and assigning responsibility for each task/sub-task, thereby showing teams how the work will progress, who will handle which tasks/sub-tasks, and where delays are most likely to occur. This is essentially project management, valuable not only in real-world engineering projects, but also in any type of project.

4.

Prototype Development and Testing

With the Gantt chart in place, teams execute the project by prototyping and refining their robots iteratively as time permits. For the robotic-based project, this phase is composed of three main components:

• Mechanical Assembly: Students construct the robot’s frame using the BoE Bot kit as the foundation. Each team is also required to design and 3D print at least one component, giving them practical experience with modern fabrication tools. Many teams choose to add extra features such as bumpers or protective casings, partly to absorb the inevitable collisions in the arena and partly to stabilise the robot during navigation.
• Electronics and Circuitry: Sensors, motors, and actuators are integrated to allow the robot to perceive and interact with its surroundings. Students design and solder their circuits, check calibration, and maintain documentation so faults can be traced when something fails, which it often does.
• Programming and Control Systems: Code ties the entire system together. It interprets sensor data, handles navigation and collision avoidance, and performs the light-deactivation task. Flowcharts are usually prepared beforehand to help teams visualise the logic and maintain clarity in documentation.

Throughout this phase, teams test repeatedly, often discovering that a small mistake in wiring or a minor oversight in code can produce unexpected behaviour. Whilst this phase often becomes a source of frustration and endless working hours, it often pushes teams to improve their robots in preparation for the competition. All teams are expected to come up with an autonomous robot that can fulfil its objective on the competition day. Its performance during the competition reflects how well all the different components are integrated together, as well as how effectively the team has worked throughout the project. As with any project, proper documentation is essential as a deliverable. Teams are expected to provide technical drawings, circuit diagrams, flowcharts, and codes, which capture not only the final robot design but also the process of arriving at that design.

It is intended that the robotics-based project would provide the students with a glimpse into a real-world engineering project, requiring the interdisciplinary technical knowledge, creativity, teamwork, and, importantly, persistence that will be essential in their future engineering career.

2.3. Supporting Modules, Assessment Approach, and Key Milestones

The module provides support for both the technical and system engineering aspects of the project, internally within the module through focused workshops, lectures, and flipped classroom sessions, as well as by relying on supporting modules. Additionally, assessment checkpoints and scheduled milestones allow the module instructor to track the progress of each team.

2.3.1. Supporting Modules and Resources

• Process-Based Support

As this module is conducted in the first semester, short, focused workshops and lectures are provided to introduce the basics of the system engineering process and project management. A more in-depth treatment of these topics is provided in the subsequent semesters of the programme.

• Design Process Workshop: Students are given a common mouse-redesign exercise, requiring them to suggest incremental innovations that can be made to an everyday product. The task is intentionally simple, but it allows them to develop their critical thinking.
• System Engineering Lectures: These sessions walk through requirement definition, weighting of selection criteria, and the use of tools such as the Pugh Matrix, work breakdown structures, dependency graphs, and Gantt charts. Together, they offer a practical introduction to the planning techniques that underpin organised engineering work.

These activities help students grasp the broader systems engineering flow, from the generation of robot requirements to the management and evaluation of design decisions.

• Technical Modules

Two parallel modules provide the technical base needed for robot development:

• Computer-Aided Engineering (CAE): Students learn 2D and 3D modelling in AutoCAD 2024, a skill that becomes essential when designing components intended for 3D printing.
• Fundamentals of Programming for Engineers: This module introduces C programming using the Code::Blocks IDE. Core topics include variables, control flow, loops, and functions, which later support sensor interpretation and actuator control in the robotics project.

• Flipped Classroom for Electronics

Electronics concepts are taught through a flipped approach, where students present materials, discuss examples, and receive guided feedback from the instructor. The format encourages them to wrestle with the material more actively and often reveals early misunderstandings before they become obstacles in the project. Topics include the following:

• Digital vs. analogue I/O in Arduino;
• LED and switch circuits with resistors;
• Voltage dividers with LDRs;
• Photo-transistor circuits for light detection;
• Ultrasonic sensor integration;
• Breadboarding and multimeter use;
• The 3D modelling and printing of custom robot parts.

• Instructor and Technical Support

Throughout the semester, instructors and lab technicians provide support where it is most needed, including for the following:

• Circuit soldering and debugging;
• Sensor calibration and fault diagnosis;
• Hardware/software integration.

The assistance is tailored rather than generic, and the aim is to bring every group to a point where they can build and troubleshoot their systems with growing confidence.

2.3.2. Assessment Approach

The assessment approach mirrors the mixed character of engineering work, where the final outcome matters but so does the path taken to reach it. Students are assessed not only on how their robots behave in the arena but also on the clarity of their documentation, the strength of their planning, and the way they operate as a team.

Technical performance centres on the demonstrated performance of the robot during the competition:

• Can it navigate autonomously using floor detection and central lights?
• Can it deactivate enemy lights in sequence?
• Can it complete these tasks by responding to collisions and without penalties?

These are supported by the final report, which includes engineering drawings, circuit diagrams, and flowcharts.

Process-based assessment evaluates students’ understanding of the system engineering process and the use of its associated tools, such as the Pugh Matrix and Gantt charts. Additionally, students are also evaluated based on their workload distribution and timely execution, aligning closely with the practical management of engineering projects. Peer review adds another layer by giving students within a team the chance to acknowledge each other’s contributions and highlight uneven efforts by some team members. The assessment is composed of the following:

• Mid-Project Report (Group, Process-Based)

Documents the early stages of the project pre-implementation, including the requirements, selection criteria, development of concepts, and the selection of the final design, using a Pugh Matrix. The report is also supported by the project management aspect of the project, outlining the implementation plan.

2.

Final Report (Group, Combined Assessment)

Documents the full system engineering process, building up from the mid-project report to post-implementation, including prototyping and the robot’s performance during the competition, as well as a post-competition reflection. The Gantt chart for the final report compares planned and actual timelines, thereby offering an opportunity for teams to reflect on their design and project management decisions.

3.

Robot Competition (Group, Technical Assessment)

Provides a demonstration of the robot’s performance, reliability, and adaptability under competition conditions, with the competition being the most entertaining part of the PBL.

4.

Team Presentation (Individually Marked)

Teams present the entire system engineering process they adopted, including their design, the challenges they addressed, the prototyping process, and the competition. Marks are given based on their understanding of the whole process, as well as their ability to respond to questions.

5.

Peer Review (Individual Appraisal)

Promotes fairness and accountability, recognising strong collaboration while highlighting any imbalance in team contributions.

2.3.3. Timeline and Key Milestones

The 15-week robotic-based PBL project follows a structured timeline to ensure progress:

• Weeks 1–3: Introduction, team formation, and requirement definition.
• Weeks 4–6: Criteria development, concept generation, and selection using the Pugh Matrix.
• Weeks 7–8: Work breakdown structure, dependency graph, and Gantt chart development, leading to task assignment.
• Weeks 9–12: Prototyping, 3D printing, and iterative testing and refinement.
• Week 13: Final testing and system integration.
• Week 14: Competition day—robots compete head-to-head in the arena.
• Week 15: Final report and peer review submission, presentations, and debrief.

This timeline offers students a grounded sense of what engineering work feels like in practice, where integrating sensors, managing mobility control, and coordinating with teammates all have to be balanced against firm deadlines. It creates an environment in which students experience the pressures and rewards of collaborative, time-bound problem-solving, offering preparation for both later coursework and future professional settings.

2.4. Research Design and Data Collection

A survey-based research design was adopted to examine the learning experiences of the students and their perceived outcomes from the robotics-based PBL activity, representing the first formal, survey-based research on this module since its implementation in 2013.

2.4.1. Research Context

Data were collected from all 43 first-year students of the four-year General Engineering programme as part of their compulsory first-semester engineering design module. Prior to the study, ethical approval was obtained from the Faculty Research Ethics Committee. Participation in the survey was voluntary, with informed consent obtained verbally and reinforced through an information statement provided at the start of the survey. The survey was administered using an online Qualtrics platform. No personally identifiable information was collected, and responses were treated confidentially, with Internet Protocol (IP) logging enabled only to ensure that each student could submit the survey only once. Additionally, as an extra measure, students were also repeatedly assured that their responses would only be used for module improvement and research purposes, their identities would not be disclosed, and participation would not have any impact on their grades.

2.4.2. Data Analysis Methods

Descriptive statistics were used to analyse response distributions and overall trends across the defined assessment domains of the quantitative part of the survey. Survey item codes were used during analysis to maintain dataset consistency.

On the other hand, qualitative responses from open-ended questions were examined using an inductive thematic approach. Initial ideas were extracted from the response, interpreted, compared, and then organised into broader categories to capture recurring patterns and to support the interpretation of the students’ learning experiences.

2.4.3. Survey Instrument Structure

The structured questionnaire was organised into four parts: background information, quantitative ratings, open-ended reflections, and questions about future aspirations. Additional details, including the full survey instrument, are provided in the Supplementary Materials (S1).

• Background and Demographics

Students entered the module from a range of educational pathways, including A-Level, HND, and the former CPE programme. Their prior exposure to programming, electronics, and CAD varied widely. For many, the systems engineering process was entirely new, making the project their first structured attempt at applying such methods in practice.

• Quantitative Assessment

A five-point Likert scale was used to explore development across five domains:

• Technical Skill Development: CAD modelling, 3D printing, Arduino programming, and circuit design.
• Process-Based Learning: Documentation quality, design selection through the Pugh Matrix, and the use of planning tools. These reflect students’ understanding and application of the structured systems engineering process.
• Teamwork and Collaboration: Task distribution, resolving disagreements, and overall group coordination.
• Overall Satisfaction and Interest: Enjoyment of the activity and interest in robotics more broadly.
• Skills Development Reflection: Perceived personal growth and alignment with the module’s intended learning outcomes.

Survey codes, e.g., TSD1–TSD5, were used during analysis to keep the dataset consistent.

• Qualitative Insights

The survey also incorporated a set of open-ended questions intended to draw out students’ own accounts of their learning. These questions encouraged them to describe the problems they faced, their approach to solving these problems, and the important moments that influenced their progress throughout the project. Their responses to these questions were examined using an inductive thematic approach, with initial ideas coded, compared, and organised into broader categories to capture patterns across the cohort.

• Future Aspirations and Impact

The survey also asked students to reflect on the influence that the project had on their interest in later modules, their confidence in their technical and process-based skills, as well as their future engineering career. Thematic reviews were performed on their responses to identify motivation, confidence, and interest in pursuing further study in areas related to engineering, particularly robotics, thereby providing an insight into how a robotics-based PBL project might influence their career choice.

3. Competition Performances

3.1. Competition Outcome and Technical Performance

The teams competed in two parallel round-robin leagues, one for each robot type, with the top two teams from each league progressing to the knockout stage. In the knockout stage, the teams faced opponents with different capabilities, thereby requiring them to adapt their earlier winning strategies to the new opponents. Scores were given based on the scoring scheme in Table 1.

Figure 3 displays the twelve robots, with Figure 3a showing the six crawler-based robots and Figure 3b the six wheel-based robots. The highest-performing teams were those that performed consistently throughout the 15-match round-robin league. In the crawler-based category, Ebirah accumulated a total of 82.5 points, with a fastest run of 51 s to complete its objective, followed by Probe with a total of 27.5 points. The wheel-based category produced even stronger results; Lightning McQueen topped the group with a total of 97.5 points and a fastest run of 21 s, followed by Thomas & Friends with a total of 70 points. These are given in Table 2. Figure 4 displays the top two robots from each category that progressed to the knockout stage, with Figure 5 summarising the final standings from the knockout stage. Lightning McQueen secured the overall first place, followed by Thomas & Friends, Ebirah, and Probe.

Figure 3. Group photo of robots, categorised as (a) crawler-based and (b) wheel-based robots.

Table 2. Round-robin competition performance results of (a) crawler-based and (b) wheel-based robots.

(a)
	MineBot	Probe	Red Bull	Ebirah	Praying Mantis	MineBot	Total
MineBot		(7.5)	(7.5)	(2.5)	20	7.5	10
Probe	12.5		10	0	0	5	27.5
Red Bull	12.5	5		5	(7.5)	10	25
Ebirah	17.5	20	20		5	20	82.5
Praying Mantis	5	5	7.5	0		5	22.5
MochiBot	2.5	5	0	0	0		7.5
(b)
	Henk	EcoBot	Kyuu Chimu	Hinz-1	Thomas & Friends	Lightning McQueen	Total
Henk		(2.5)	5	2.5	0	5	10
EcoBot	7.5		5	5	5	(2.5)	20
Kyuu Chimu	5	5		5	20		35
Hinz-1	2.5	0	5		5	0	12.5
Thomas & Friends	20	20	5	20		5	70
Lightning McQueen	20	17.5		20	20		97.5

Brackets () indicate negative marks.

Figure 4. The two top performing robots of each category, with (a) Ebirah and (b) Probe of the crawler-based robots, and (c) Lightning McQueen and (d) Thomas & Friends of the wheel-based robots.

Figure 5. Results of the knockout stages among the four robots: Ebirah, Probe, Lightning McQueen, and Thomas & Friends.

The outcomes of the knockout phase demonstrated the differing strengths and limitations of crawler-based and wheel-based robots. Crawler robots generally provide steadier handling, particularly on uneven surfaces; however, this is less significant on the smooth arena surface. Their movements have the effect of varying their orientation, which makes it harder to consistently detect floor colour and target lights. Additionally, their relatively larger size limits manoeuvrability, especially in the tight spaces of the arena. Consequently, teams with crawler-based robots tend to focus on reliability and sensor calibration over speed. On the other hand, wheel-based robots are generally faster and can navigate tight spaces more efficiently due to their relatively small size. Combined with precise sensor calibration, wheel-based robots are able to achieve their objectives with minimal time, as demonstrated by Lightning McQueen’s fastest run of only 21s. However, their relatively small size may also represent a disadvantage, particularly during collisions.

As the competition progressed over the morning, inevitable variations in ambient lighting also represent another challenge, necessitating teams to recalibrate and adjust their detection thresholds. These small adjustments often determine the ability of the robots to fulfil their objectives effectively. Throughout the competition, teams also continued to make minor refinements to their robot designs, for instance, by adjusting sensor placement and adding a stabilising weight. Ultimately, the robots that performed the best were those that could combine speed, robust sensing, and efficient programming logic, as well as the teams’ ability to respond effectively to unexpected problems.

3.2. Design Challenges and Solutions

The robot-based PBL project highlighted several technical and process-based challenges faced by the students. Many of these challenges stemmed from limited prior exposure to coding, electronics, mechanical design, and structured engineering process, thereby making the task of building an autonomous robot challenging for some teams.

Programming was one of the areas that students found challenging, despite the simultaneous running of the programming module, with many teams struggling to integrate code from different subsystems into a logical sequence and correct logic errors. Flowcharting helped to an extent, but the experience suggested that the PBL project may benefit from more structured programming guidance, especially in building and debugging a large integrated codebase. Electronic challenges were mostly related to understanding circuit designs, which is understandable given the absence of formal foundational teaching on the topic. Some teams also struggled to produce accurate solder joints and maintain reliable wiring, with loose connections or faulty components frequently leading to erratic sensor behaviour. Most teams resorted to trial and error to solve electronic issues, which highlights a gap in the use of routine diagnostic methods, such as using a multimeter for checks. Power management presents another challenge; teams with complex robot configurations performed effectively during the earlier stages of the competition, but were unsure of what to do when their robots acted erratically at the later stages due to insufficient power. Mechanical work presented challenges as well, albeit these were generally less severe, with the teams able to solve these challenges after some iterations. Students encountered minor difficulties in CAD modelling, particularly when designing parts that aligned correctly; some of these problems only became apparent after 3D printing. Many teams also required several design and printing cycles before producing fit-for-purpose bumpers or sensor mounts.

The most significant challenge, however, occurred after integrating the different subsystems. For instance, a problem caused by mechanical misalignment or a loose wire could easily be mistaken for a software error, as teams realised only after spending long hours debugging that issues in one domain could overspill into others. These instances reinforced the importance of holistically viewing the robot as an integrated system rather than as a collection of subsystems performing separate tasks.

The teams also faced several process-based challenges. Whilst all teams managed to produce Gantt charts, not all maintained realistic timelines, with some scheduling dependent tasks to run in parallel without realising the implications. These oversights only became apparent during project update sessions or when one task could not move forward without the completion of another task. Uneven task distribution also slowed the progress of some teams. Ultimately, teams that communicated effectively were able to adapt quickly with the emergence of unexpected problems or with the realisation of an earlier unworkable plan.

Despite the numerous challenges across different domains faced by the teams, they have demonstrated observable improvements in practical technical knowledge, problem-solving skills, and critical thinking abilities. The identified challenges are indeed typical challenges faced by those who are just beginning to work with integrated systems, reflecting the learning curve of early-stage engineering development. It is encouraging to note that these challenges can be expected to diminish with experience, as students progress in the programme.

4. Student Utility and Learning Outcomes

This section is organised following the organisation of the survey, with findings presented across demographics, quantitative assessment, qualitative insights, and future aspirations. While the quantitative and qualitative results are reported in separate subsections for methodological clarity, they address common learning themes and are synthesised in the Conclusion to provide an integrated interpretation of the students’ learning experiences.

4.1. Demographics and Background of the Students

The survey captured responses from all 43 first-year students taking the Engineering Design 1 module. As shown in Figure 6a, almost half of the students (20 students) were 19–20 years old, with only one student at either end of the range, at ages 18 and 25 years old. The gender distribution leaned slightly toward male students, at 58%, as shown in Figure 6b, which broadly reflects the annual enrolment patterns of the engineering programme. Figure 6c illustrates the range of academic pathways of students enrolling on the programme. Students arrived from A-Level and Chemical and Process Engineering (CPE) transition routes, each comprising 35% of the students, while the remaining 30% consisted of students with Higher National Diplomas, mostly in areas such as Petroleum Engineering or Power and Plant Systems. This diversity reflected the different technical knowledge and perspectives of the students.

Figure 6. Demographic distribution and background of students: (a) age distribution of students, (b) gender distribution, (c) educational background of students, and (d) experiences of the students in computer-aided design (CAD), programming, electronics, and system engineering process.

However, despite the varied backgrounds, Figure 6d demonstrates that most students had limited exposure to robotics-related skills, such as 3D design, programming, electronics, and systems engineering processes. Approximately 80% of the students had no prior experience in systems engineering or electronics. Only slightly better gaps are observed in programming and CAD work. These highlight the critical need for providing structured approaches that enable students to develop relevant practical skills earlier in their studies.

4.2. Quantitative Assessment

Figure 7 shows the outcomes from the quantitative components of the survey. Outcomes for technical skill development (TSD1–TSD5), process-based learning (PBL1–PBL6), teamwork and collaboration (TC1–TC4), and overall satisfaction and interest (OSI1–OSI3) are in Figure 7a–d, respectively, clustered strongly around the “Agree” and “Strongly Agree” scales.

Figure 7. Summaries of student responses of (a) technical skill development (TSD1–TSD5), (b) process-based learning (PBL1–PBL6), (c) teamwork and collaboration (TC1–TC4), and (d) overall satisfaction and interest (OSI1–OSI3).

In terms of technical skill development in Figure 7a, an average of 83% of the students agreed that the robotic-based PBL project increased their confidence in the main technical areas (mechanical design, programming, and electronics) as well as autonomous system development and practical implementation. Strong positive responses of above 90% came from mechanical design (TSD1) and electronics (TSD2). Students appreciated how the PBL project helped in their understanding of practical mechanical and electronic designs and turning these designs into something tangible with the use of engineering tools, such as CAD softwares, a 3D printer, and hands-on circuit building. However, programming (TSD3) reported a lower percentage of improvement, with only 54% of students answering positively. Despite this, 44% responded neutrally with only a small number of negative responses, suggesting that whilst most of the students recognised some improvements to their programming skills, they were not confident enough to describe it as a substantial improvement. Programming skills require structured logical thinking and commonly develop gradually with practice. Hence, for new students, improvements may feel quite insignificant in relation to the overall codebase that they need to write. This highlights the need for increased support for programming, particularly in relation to its application to the PBL project. A perfect 100% positive response came from the practical application of theoretical knowledge (TSD5), an expected but nevertheless satisfying outcome as the focus of PBL is to provide a bridge between theory and practical implementations.

For the avoidance of doubt, the labels PBL1–PBL6 refer specifically to survey items associated with process-based learning, as defined in Section 2.4.2, whilst “PBL” refers to project-based learning. Figure 7b depicts the survey outcomes in relation to the process-based components of the module, particularly in relation to students’ understanding and application of the system engineering process described in Section 2.2, including requirement capture, design development and selection, and project management, as necessarily adopted for the robotic-based PBL project. Students generally responded positively to them, with an average of 88% students responding with “Agree” and “Strongly Agree” across PBL1–PBL6. The strongest positive responses of 95% were in relation to recognising the value of structured engineering processes in engineering (PBL6), which represents one of the main objectives of this module. Students also expressed confidence in documenting requirements and design decisions (PBL1), converting competition objectives into system requirements (PBL2), project management skills, including work breakdown structures and Gantt charts (PBL4), and engaging in iterative testing and refinement (PBL5), with scores of 88%, 91%, 87%, and 91%, respectively. The one area with a noticeably lower score was PBL3: the development of selection criteria and the use of a Pugh Matrix for design evaluation, with 74%. This suggests that identifying the selection criteria after specifying the system requirements and using them for early-stage design selection remains less familiar to many. Overall, the results indicate that students responded well to the systematic nature of the module, gaining a clearer sense of how structured processes support engineering work.

Teamwork and collaboration have a somehow lower overall average of 74%. As shown in Figure 7c, 74% of students generally agreed that their teams collaborated effectively by leveraging their diverse skills (TC1), with the teams able to constructively manage conflicts and consider diverse perspectives (TC2 with 81%). However, the lowest score in this category came from TC3, with only 65% agreeing that the team members contributed equally based on their strengths. This likely reflects situations where tasks were initially divided evenly during the initial scheduling phase, but as the project progressed, certain tasks, especially programming, ended up requiring more time than initially predicted. This is common in first-year projects and underscores the importance of predicting the requirements for a task and, if necessary, putting more manpower on delayed tasks. Even with these challenges, a majority of 74% of the students still reported a positive learning experience with their teammates (TC4). Overall, these results suggested that teamwork and collaboration is an area where students have gained meaningful positive experience, but with better and adaptable project management strategies.

As shown in Figure 7d, 91% of the students reported that they are satisfied with the learning experiences from the robotic-based PBL project (OSI1), with 82% even indicating that they would recommend the project to other students (OSI3). Increased interest in robotics and engineering from this project (OSI2) is relatively low with 75% of students giving a positive response; however, this is more encouraging when viewed alongside the remaining responses, which all have selected “neutral”. Whilst a majority reported increased interest from the project, none of them were discouraged from robotics and engineering by the project. Overall, the survey results reported positively in terms of overall satisfaction and interest, with an average score of 82%.

Overall, the quantitative survey outcomes indicate strong learning gains across technical, process, and teamwork components, resulting in an overall high level of satisfaction with the robotic-based PBL project. The open-ended question on skill development, given in Figure 8, adds more insights into these results. Problem-solving emerged as the most frequently mentioned area of improvement from 31 students, followed by teamwork from 27 students. A total of 26 students reported improvement to their project management and systems engineering skills. Technical areas, such as mechanical design and electronics, also appeared often with 25 students each, whilst programming was mentioned slightly less, with only 20 students, reflecting our earlier results. One student chose the “Others” category and highlighted time management and effective use of online resources as an improvement area.

Figure 8. Areas of improvement reported by students during the PBL project.

Almost all students (41 out of the 43 students) felt that the robotic-based PBL project prepared them well for future engineering challenges. Some students pointed to a clearer understanding of the interaction between mechanical, electrical, and software components, i.e., system integration, as their main reasons. Others pointed to improvements in multitasking and time management, due to the deadline given, as well as the opportunities to improve their communication, leadership, and team coordination from the group work, as their reasons. However, a small number of students raised that they would have benefited better with more guidance during the initial development stage of their robot and in managing communication between team members. Others also suggested broader exposure to different engineering problems before they can feel more confident in carrying out the project. These suggestions are natural for new engineering students, and it is due to these that we are introducing this PBL project; it is better for the students to experience this now in the safety of the classroom rather than in their workplace. It also pointed out that while the open-ended nature of PBL encourages autonomy, some students may still need more structured support.

As shown in Figure 9, 33 students felt that the project matched with its intended learning outcomes, with 24 students agreeing and another 9 expressing strong agreement. However, 10 students chose a neutral response, with none disagreeing. These indicate that the robotic-based PBL project nicely supported the aims of the module. Several students suggested a slightly longer timeline to complete the project, more explicit guidance on time management, and clearer accountability for individual roles, to improve alignments. These suggestions point toward future small practical adjustments that could make the learning experience even smoother and help students engage more fully with the module outcomes.

Figure 9. Student responses on the alignment between the project and module learning outcomes.

4.3. Qualitative Insights

To complement and contextualise the quantitative survey outcomes given in the previous section, the qualitative section provides a closer look at how students experienced the PBL project, by inviting them to describe the different challenges and their proposed solutions, the skills gained, and the value of teamwork, as well as reflect on what they would change if given the chance.

4.3.1. Technical Challenges

Many students pointed to the sheer technical weight of the PBL project, especially for new students with limited technical experience. They highlighted programming as the steepest climb for many of them; sentiments felt by the author during his earlier engineering journey as well. As most students had little or no coding background, they found it especially difficult to integrate the different functions of the subsystems into a single working program. One student commented that “getting all sensors, motors, and code to work together was much harder than I had expected” (student response to Q33). Combinations of different errors often surfaced at once, ranging from coding errors, such as syntax errors, logic errors, and timing errors, to hardware-related errors related to sensors or wiring. In a few cases, bugs kept coming back no matter how many times the code was rewritten, making debugging seem an endless task. However, many students acknowledged that this slow and extremely frustrating cycle of testing and fixing taught them persistency and improved their way of thinking, both of which are important characteristics of a hardcore programmer. One student commented that “debugging taught me what frustration means, forcing me to be more patient and to think step-by-step instead of blindly guessing solutions” (student response to Q35).

Electronics also proved to be equally challenging, particularly for students coming from the theoretically heavy A-Level. Without a formal electronic module to spoon-feed them, they had to learn basic circuit design, as well as the practical sides of electronics, such as circuit-building and soldering, through hands-on practice. Faulty connections, unstable readings, and failed sensors were common, exacerbated by their limited debugging skills. One student commented that “a simple wiring mistake e.g., loose connections, stopped my robot from working multiple times” (student response to Q33). These difficulties highlighted the importance of basic diagnostic tools, such as a multimeter, for the students to systematically identify faults. Strengthening these foundational troubleshooting skills would be a clear area for improvement, either within future iterations of this module or in the modules that follow.

Mechanical design also presented some challenges, though most students found these issues more manageable than the programming or electronics problems. Several teams found that 3D models which may have looked perfectly fine on the screen revealed misalignments or weak points once 3D printed, requiring them to repeatedly reprint bumpers, mounts, or protective casings. Many students found this design process satisfying though. Seeing a rough sketch on paper evolve into a digital 3D drawing and then into a real, working component gave them a different level of satisfaction. One student described the PBL project as “the first time I had designed and actually made something real” (student response to Q40).

A recurring theme through all the responses was the difficulty of integrating everything, mechanical, electronic, and programming, into a single working robot. A bracket that is a few millimetres off its intended placement could throw a sensor out of alignment, and a loose wire or a component placed in the wrong place could create havoc in the entire robot. These highlighted that a robot is never just a collection of separate parts. Rather, its behaviour emerges from how those parts interact, sometimes in ways that are not obvious until something goes wrong. One student commented that “changing even one small thing can affect everything and turned the robot upside down” (student response to Q33). The experience forced them to think in terms of whole systems rather than isolated parts, and, hence, system engineering.

4.3.2. Process Based Challenges

The focus on the systems engineering process pushed students to work in a way that was more systematic than what they were used to. As per the system engineering process, they had to start with requirement capture to think about and document what the robot actually needed to accomplish its tasks. They also learnt a systematic way to choose the best design by comparing different designs against a set criterion before moving to the project management part, and then to execution. The brief lectures did give the students the broad outline of the process, but they were the ones that had to put this theoretical process into practice. One student commented that “the first time we had to specify what the robot must do before starting to design” (student response to Q34).

Their responses suggest that most groups did manage to put into the practice the systematic process. They began by breaking the competition objective into smaller, functional requirements, such as motion, floor sensor, or target light requirements. Group brainstorming sessions and independent searching, often supported by modern tools such as ChatGPT, as well as instructor–students discussions, helped them develop these requirements. A particular challenge highlighted by the students, even during the module, was the development of the selection criterion. This issue was addressed during the project through focused lectures by the instructor, which assisted the teams in developing the proper selection criterion and subsequently allowed them to choose the best design more systematically. As one student commented, “deciding on proper criteria was harder than choosing the design itself; but it is easier to provide justification on the why” (student response to Q34).

Many students initially reported difficulty in understanding the relationship between the work breakdown structure, dependency graph, and Gantt chart, with students highlighting that the concept seemed abstract and that they were unsure how one should inform the next. Through group discussions and after a few rounds of revision, however, most students made sense of how the tools fit together, to arrive at a Gantt chart. However, many teams treated the Gantt chart mainly as a requirement to be included in the report rather than a tool to guide the project. As deadlines tightened and with the instructor repeatedly requesting project updates by referring to the Gantt chart, students started to see its importance. One student commented that “we only realised how useful the Gantt chart was when the instructor started asking us why we were behind schedule; and to find reasons for it” (student response to Q35). They began using it not simply as a formality and to respond to the instructor but as a practical way to divide work sensibly, anticipate bottlenecks, and keep everyone aware of what needed to happen next. Unfortunately, by the time many teams realised its importance, most were already behind schedule. Nevertheless, tasks were aligned with each member’s interests to assist with the timeline, with regular team discussions, via WhatsApp as well as in person, and small milestones playing important roles in keeping the project from drifting too much.

Several students also emphasised the need to be adaptable and the importance of teamwork. When the timeline was delayed, they needed to step in to help one another and to recover lost time. Some teams highlighted groupwork approaches that worked particularly well for them, such as keeping documentation in the cloud, regular group meetings, and having unscheduled brainstorming sessions to make quick decisions when needed. One student commented that “good communication skill is important when problems occurred and plans had to be changed unexpectedly and on the spot” (student response to Q36). These reflections show how students navigated the process-based challenges by mixing structured system engineering with flexibility, as, in practice, systems engineering is far from ideal. These experiences represent an important learning process on managing a practical multidisciplinary engineering project.

4.3.3. Skills and Knowledge Development

The project gave students a wide range of chances to build both technical and process-based skills that underpin real engineering work. Through a mix of hands-on tasks and constant problem-solving with their teammates, the students had to work within mechanical design, electronics, programming, and project management domains, and more than often, be cross-disciplinary within these domains, shifting between these domains within the same week. One student commented that “we had to switch between coding, wiring and design constantly, which felt very challenging” (student response to Q40).

In mechanical design, students improved their skills in 3D modelling and printing, using design software, such as SolidWorks and Fusion, and 3D printing software, such as Creality slicing software, to design and produce the parts that are actually needed for the robot to complete its tasks. Whilst basic 2D drawing skills were introduced through the accompanying CAE module, students had to self-learn 3D modelling and printing. The self-learning practical process required multiple design and printing iterations on even simple parts, such as bumpers or sensor mounts, highlighting how minor design choices can affect the entire system. One student commented that “small changes in the design sometimes made a big difference once the part was 3d-printed and installed” (student response to Q33). Most students, especially those from the non-technical A-Level routes, also learned a lot of electronics from the PBL project. They had to learn circuit theory and move to practical circuitry, where they had to build simple circuits, calibrate sensors, and solder connections, and, of course, debug problematic circuits. Interestingly, the students highlighted the need for accuracy in building circuitry, and the consequences of simple but troublesome mistakes, such as a loose wire. One student commented that “a simple wiring mistake, e.g., loose connections, stopped my robot from working multiple times” (student response to Q33). Programming was also another steep learning curve for many of the students. With most of the students having no coding experience, they understandably struggled early in the project, but eventually learned, especially with pressure from the closing deadline, to debug and make the robot move. The students reported increased understanding of using code to translate sensor inputs into planned behaviour.

Alongside improvements in technical skills, the students also gained understanding of process-based skills, particular system engineering, with the PBL project. Students had to produce requirement documents, set selection criteria, justify their selection, and organise their work using project management tools, such as work breakdown structures, dependency graphs, and Gantt charts. Whilst the students reported finding some of the process steps to be abstract, most of the students only really understood the importance of these steps once the project was implemented and encountered problems. For instance, a few students only realised the importance of the dependency graph when problems, such as the unavailability of certain components, forced them to rearrange task sequences, at which point the dependency graph they had drawn earlier suddenly became a practical guide rather than a formality. One student commented that “WBS, Dependency Graph only made sense once things started going wrong” (student response to Q35). These experiences highlighted the benefits of PBL. The students also learned a lot from working in a team, requiring them to communicate effectively, allocate tasks efficiently, and resolve problems professionally.

By combining technical and structured system engineering developments, the PBL project provided the students with invaluable practical experience, albeit on a smaller controlled environment, to better prepare them in their engineering journey.

4.3.4. Teamwork and Collaboration

Teamwork and collaboration are considered professional competencies, and extremely important competencies indeed for engineers, with students’ engagement in the robotics-based PBL activity forcing them to work in a team and collaborate. They are often referred to as soft skills in engineering education. Most of the time, the importance of teamwork only becomes apparent when students reached points where individual solo effort was no longer sufficient to keep the project going forward. This tended to happen during high-pressure moments, such as towards the end of the project or between matches during the competition. One student commented that “when things started going wrong, it was impossible to fix everything alone” (student response to Q36). Several students described situations during system integration where the robot simply refused to behave as expected. A loose wire caused by improper soldering, mismatched lines of code, or even insufficient battery power could cause the robot to misbehave. It was during these situations that team collaboration made all the difference, with team members pitching small but significant efforts to try and solve a common problem; one student would step through the program line by line, another would systematically diagnose the circuitry for faults, and yet another would conduct research on the possible sources of the problems. One student commented, “working together helped us find and solve problems much faster than solo work” (student response to Q36). These collective efforts would allow them to identify and solve the problem faster than if each student had worked alone. Another student described situations during the competition when his robot suddenly stopped moving due to power dropping below the minimal level, with the team members managing to identify and solve the problem with minimal time.

Students also described situations a few days before the competition, forcing the team to simplify their design quickly and basically, to make the robot work. When the ultrasonic sensor for the collision detection caused long delays in the code and programming tasks began taking longer than initially planned, team members redesigned their robot to use a bumper switch within a day and redistributed responsibilities to complete the robot within a week. One student commented that “changing the design last minute only worked because everyone agreed and helped immediately” (student response to Q36). In other situations, students with more experience, particularly those from HND backgrounds, stepped in to help their teams beyond their pre-assigned tasks, to avoid delays in their timeline. In fact, students’ willingness to help was not limited to their own groups; several students described assisting or receiving assistance from other teams in terms of advice, quick fixes, or lending unused components when others encountered problems. One student commented that “it felt more like a shared learning experience than just a competition” (student response to Q40). This is very encouraging to see, reflecting a strong sense of team spirit, and showed that for many students, the PBL project was not viewed merely as a competition but as a shared learning effort.

These situations with teams relying on joint effort to overcome challenges showed that strong teamwork can improve problem-solving, create better solutions, and keep projects on track, mirroring multidisciplinary engineering, where teamwork is a necessity instead of a luxury.

4.3.5. Reflections on Learning and Problem-Solving

The students were also asked to reflect on how they would approach the project again if given a chance, and how the project had affected their approach to learning. Many answered with practical and thoughtful changes for the next time, and, fortunately, by design, they will have that opportunity to implement these changes in the engineering design modules that follow.

Many students noted that teamwork was a “must”, especially when the work became really technical for them, when they were compressed with deadlines toward the end of the project or between matches. Integrating mechanical, electronic, and programming often necessitated a group effort, since small issues such as misaligned parts and loose wire connections can be a source of headache for the team. One student commented that “it was impossible to manage everything alone once integration started; too much to do and think about. Group work is important” (student response to Q37). They also highlighted the importance of dividing tasks according to individual strengths or at least the interest of team members; this was particularly worrying for the instructor as one of the intentions of these engineering design modules is to introduce these different domains to the students.

Students also noted the importance of steady communication and shared problem-solving to keep the project going. Regular team meet ups, informal discussions, and brainstorming sessions were necessary to prevent small problems from snowballing into bigger problems, with some students suggesting that team members stay in touch almost constantly through a WhatsApp group and solve a problem when and whence it came up. One student commented that “quick communication would have helped us stop small issues from becoming larger” (student response to Q37). When they reflected on the project afterwards, many students learnt that they would have to manage their time more effectively. They identified procrastination as a real issue, especially at the early stage when towered by the sheer volume of technical work to be completed, and the importance of having a “just do it” attitude. They can now also see the importance of having a good work breakdown structure to allow them to see the bigger task as small manageable mini-tasks. One student commented that “breaking the project into smaller tasks made everything feel more manageable” (student response to Q37). Several students suggested scheduling longer durations for integration and testing, as they had experienced that debugging and calibration were taking them the most time, and not the designs. On the other hand, some students suggested putting more care into the design stages, as deficiencies in these stages were the ones causing the problems in the later stages. These contrasting views likely reflect their differing experiences during the PBL project: those who encountered problems during integration naturally wished that they had put a longer integration timeline, while those whose designs revealed weaknesses only at a later stage would naturally wish that they had put more thought into their early designs.

Some students also suggested that distributing key tasks, especially programming, across more team members would have created a more balanced workload. A few students recommended structuring tasks around subsystems that they had to build, such as the floor sensor, navigation, or target light subsystems, rather than around disciplines. One student commented that “working by subsystems would have helped everyone feel more responsible for a complete part of the robot” (student response to Q40). They felt that this approach might have created a more balanced workload and encouraged broader involvement and clearer ownership of outcomes.

Collectively, their responses showed an increasing awareness of the importance of breaking down complex tasks into manageable tasks, good task distribution, working through problems in a systematic and steady way, not procrastinating, and maintaining communication within group members. As part of the learning spines, these realisations are important for them to implement in the next stages of the engineering design modules.

4.3.6. Application to Future Engineering Challenges

More than 74% of the students felt that the project had given them applicable skills for their future engineering work, with the remaining students unsure of its applicability. This suggests that the PBL project was broadly seen as beneficial for their development.

Many students highlighted programming and integration as the most valuable areas of development. Students appreciated the practical elements of the project, and described how they had learned to convert sensor readings into meaningful actions via codes, to debug these codes more systematically, or to integrate all the different hardware and software components in a way that only made sense after repeated trial and error. One student commented that “the project made programming feel useful rather than abstract” (student response to Q40). These skills were often linked to the engineering field, particularly robotics and automation.

Mechanical design came through as an area that interested the students greatly. Refining a bumper or adjusting a sensor mount in SolidWorks or Fusion, and then using rendering software before 3D printing, helped the students to fully understand how ideas turn into digital representations before becoming physical components, and increased their appreciation of how small changes in a model can influence the strength and fit of the components. These experiences helped them to move from the theoretical concepts learnt in their CAE module to more grounded and practical engineering practices. One student commented that “seeing a design go from screen to a real part helped me understand engineering better” (student response to Q40). Several students also pointed to learning circuit design, prototyping, and soldering, as well as sensor calibration, as useful foundations for electronic work, in particular in relation to real-time control.

Process-based skills were also mentioned in the student responses. Students recognised, albeit towards the end of the project for some teams, the value of project management tools, such as dependency graphs and Gantt charts, for coordinating tasks, keeping the project on schedule, and for performing quick reshuffling of tasks when necessary. They also emphasised the need for better time management among the team members, and, importantly, effective communication when working as a team. One student commented that “planning tools became important once things stopped going according to plan” (student response to Q40). Many students remarked that teamwork was not simply about the division of work, but more importantly about supporting one another when the work became just too difficult for a single person to solve or when unexpected problems arose, and this extends to non-team members as well.

Even students who were unsure about the relevance of the PBL project to their engineering careers still acknowledged improvements in their basic technical knowledge, problem-solving skills, and overall increase in confidence in carrying out hands-on work. The survey responses clearly have shown that the PBL project has successfully helped students in linking their academic and theoretical learning to practical real-world engineering challenges.

4.4. Future Aspirations and Impact

The hands-on and interdisciplinary nature of the robotic-based PBL project greatly affected many of the students, including their views on engineering work and their future aspirations.

As shown in Figure 10a, over 40% of the students reported an increasing interest in taking robotics projects in the future. Several students pointed to the simple satisfaction obtained from seeing the robot work because of their circuitry and codes, sentiments expressed by most of the students during their presentation. For some, their interest in pursuing robotics emanated from the level of technical reasoning and creativity involved in the PBL project, which combined mechanical design, electronics, and programming, to build a robot to achieve a particular task. More than half of the students (53.5% of the students) answered “unsure” when asked whether the project has increased their interest in future robotics project, with only 4.7% reporting a “no”. It should also be noted that even those who were unsure still recognised value in the experience, with some students expressing an eagerness to broaden their roles in future projects. Programmers wanted to try circuit design, those who focused on electronics wanted to contribute more to the mechanical side, and those focusing on mechanical design wanted to contribute to programming in the future robotics projects. A number of the students described a growing curiosity, often sparked by the moment their robot first worked. One student summed it up simply by saying that it made them wonder what else they could build.

Figure 10. (a) Distribution of students’ interest in pursuing advanced robotics courses, (b) students’ interest in pursuing additional training or learning opportunities in robotics, electronics, or programming, and (c) students’ confidence levels in completing future compulsory robotics projects.

In terms of the confidence levels of students in future robotic projects, such as the following engineering design modules in their programme, 58% of the students expressed confidence in taking up further robotics projects, and about a third were uncertain, with a small minority feeling not confident, as shown in Figure 10c. Those who expressed confidence often pointed out their vast improvements in programming, electronic circuitry, and teamwork, obtained from the PBL project. The uncertain group of students seemed to want more guided practice before they can feel suitably confident in their abilities, while the few without confidence had cited difficulties with programming or system integration as their main reasons. Results on the preference for robotics-related final-year projects followed a similar pattern. Totals of 7% and 27% of the students said that they were very likely and somewhat likely to pursue such robotics-related final-year projects, respectively, with nearly half of the students remaining neutral and only a very small number of students leaning slightly away from robotics. Notably, none expressed complete disinterest in taking up a robotics-related project. When confidence levels and interest in pursuing robotic-related projects are examined together, it can be seen that among the confident students, 60% of them expressed a likelihood of selecting robotics-related topics for their final-year work, with about a third staying neutral. For those uncertain students, 25% and 69% expressed likelihood and neutrality, respectively. It is clear that, whilst confidence level does play a part, it is not the only factor determining students’ choices. Personal interests and exposure to the different engineering fields may also have an influence.

However, when students were asked about their interest in pursuing additional training or learning opportunities in robotics, electronics, or programming (Figure 10b), 37% expressed clear interest, with the remaining 63% still expressing interest but a little pinch of hesitancy. Importantly, not a single student chose the “Not Interested” option. This suggests that whilst not all students were fully ready and confident to take on their next robotics projects, the PBL project succeeded in cultivating at least a basic curiosity. Building on this, the instructor has already introduced voluntary robotics mini competitions during their month-long semester break, for students to explore robotics further without feeling overwhelmed.

Students were also asked about aspects of the PBL project which have inspired their interest in engineering and robotics. Many students pointed to small, almost unexpected discovery, such as finding the robot to behave entirely differently just by shifting a sensor by a few millimetres or rewriting a few lines of code. One student commented that “changing a small part of the code or sensor position completely changed how the robot behaved” (student response to Q45). These instances made system integration feel more real and showed them how simple design choices can make a difference to the entire system. Activities like 3D modelling and iterative prototyping were often mentioned as well. They combined technical reasoning with creativity, allowing students to see how ideas evolve through testing and readjustment, blended with patience and perseverance. As one student commented that “seeing an idea slowly improve through testing made engineering feel rewarding” (student response to Q40).

Teamwork and collaboration also came up repeatedly as a source of inspiration. Peer discussions, shared problem-solving, the exchange of tips between students belonging to different teams, and, generally, moral support helped many students discover their strength of perseverance that they did not realise they had, allowing them to complete their tasks. For those with little or no background in any of the technical domains, these broadened their sense of what they might pursue in later years.

Collectively, these comments from the students suggest that what inspired them most was not a single tool or task, but the combination of hands-on experimentation, visible cause-and-effect, and the feeling of collectively solving problems. These experiences helped them to bridge the gap between abstract theoretical concepts and practical engineering work, while still providing the impetus for them to explore robotics more deeply.

Table 3 summarises the key quantitative trends and dominant qualitative themes across the major domains.

Table 3. Summary of key learning outcomes from the robotics-based PBL project.

Learning Dimension	Key Quantitative Trend	Dominant Qualitative Themes	Related Sections
Technical Skill Development	High agreement (≈83%+)	Programming, electronics, and system integration identified as most challenging but rewarding	Section 4.2, Section 4.3.1 and Section 4.3.3
Process-Based Learning	Strong agreement (≈88%)	Students recognised value of structured systems engineering, especially after encountering integration issues	Section 4.2 and Section 4.3.2
Teamwork and Collaboration	Moderate–high agreement (≈74%)	Team coordination critical during integration and competition phases; peer support extended beyond teams	Section 4.2 and Section 4.3.4
Confidence and Interest	Majority positive	Increased confidence, resilience, and interest in robotics and later design modules	Section 4.4
Systems Thinking	Not directly rated	Students shifted from component-level thinking to system-level reasoning	Section 4.3.1, Section 4.3.2 and Section 4.3.3

5. Conclusions

Engineering education has increasingly moved beyond traditional lecture-based teaching into more innovative learning approaches. The shift has become more urgent as modern engineering practices have put greater and greater emphasis on interdisciplinary work and collaboration, both of which require learning environments that mimic these real-world scenarios. Within this context, a robotics-based project-based learning (PBL) project has been implemented as part of the faculty’s engineering design spine, providing an illustration of what such innovation in engineering education can look like. By asking first-year fresh students, some with no background in engineering, to design, prototype, and program autonomous robots, the PBL project helped close the gap between abstract theory and hands-on engineering practice. The PBL project created a learning environment where ideas had to be tested and reiterated through the direct engagement between real hardware and software. This approach is consistent with prior studies in engineering education, which have shown that PBL does support deeper understanding of technical concepts, systems-level thinking, and student engagement, particularly when learning activities mimic real engineering work.

Many students reported improvements in both their technical and process-based skills through the robotic-based project-based learning (PBL), with average positive responses of 83% and 88%, respectively. Similarly, an average of 74% of the students reported improvements in their teamwork and collaboration skills. Overall, 82% of the students reported satisfaction from the robotic-based PBL project. The survey data showed that 54% of the students were more confident in tackling future robotics projects, with 37% of the students expressing a strong interest in deepening their skills in robotics and about a third of the students indicating that they were now considering robotics-oriented topics for their final-year work. Qualitative survey responses showed similar findings. Students described learning to integrate systems more effectively, think iteratively, manage projects with greater awareness, and draw on each other’s strengths in interdisciplinary teams. Several students also mentioned that the experience encouraged them to explore roles that they had previously avoided and helped them to build resilience in the face of technical setbacks. Beyond the technical aspects, students also improved their soft skills: teamwork, communication, and adaptability were tested throughout the project. Many students highlighted the challenge of coordinating efforts between team members under time pressure and the value of decision making under uncertainty as part of the engineering process. More importantly, the PBL project allowed the students to develop their team spirit, with students willing to assist one another irrespective of their teams. Taken together, these outcomes align with prior studies on the efficacy of robotics-based PBL in supporting technical, process, and professional skills development, whilst additionally demonstrating that such benefits can be harnessed even during the very beginning of an engineering programme among students with limited prior technical exposure.

The PBL project was, of course, not without its challenges. While students made considerable progress in areas such as mechanical design, many struggled with programming, electronic circuitry designs, and the uneven distribution of tasks within teams. These difficulties point to a need for more structured guidance, particularly for students entering the module with little or no prior exposure to electronics or coding. Such structured learning could help ensure that all team members benefit more evenly from the experience.

The competitive element added another dimension by forcing students to confront real engineering trade-offs within limited time frames. Contrasting the performance between crawler-based and car-based robots illustrated how design decisions interact with their environments, with car-based robots generally able to move faster and accurately across the arena, whilst the crawler-based robots, commonly associated with stability on uneven terrains, gained very little stability advantage due to the flat arena. In practice, their added bulk and the occasional sensor inconsistencies became more noticeable than any stability benefit. Working through these differences gave students an understanding of how design choices must often be negotiated rather than simply selected.

This study offers several useful considerations for engineering educators aiming to strengthen engineering curricula through hands-on, interdisciplinary, robotic-based PBL. Whilst the project is limited by the semester time, dedicated programming and electronic workshops may assist fresh engineering students in the project, and not just traditional workshops but ones fully integrated to the PBL project. Clearer mechanisms for balancing team contributions need also to be put in place. Even with these, the robotics-based PBL project, which immerses the students in cycles of design, prototyping, testing, and reflection, already stands out as a meaningful learning experience, effectively helping them to develop both the technical and teamwork skills that are needed to engage confidently with the increasingly complex demands of real-world engineering work. Overall, the results highlight the importance of carefully scaffolding early-stage PBL activities, particularly in programming and electronics, whilst still giving genuine opportunities for students to engage with system integration and teamwork challenges, which make up the essence of real engineering work.

However, this study is not without its limitations. Only a single cohort within one programme was considered, with data primarily from self-reported survey data, which may not fully capture all learning objectives. Being a part of a semester-long module, this also constrained to some extent the technical skills that the students could develop. These limitations, however, represent more opportunities for further elaborate studies, particularly on tracking how early exposure to robotics-based PBL influences students’ learning journeys, confidence, and engagement in later engineering design modules. With the module being the first part of an eight-part series of design spine modules, the progressions of the students as they progressively transversed the series would undoubtedly be an interesting addition to this current study.