In my own teaching practice, the rapid spread of Industry 4.0 has transformed the classroom from a place where students merely memorize commands into a laboratory where they must think, design, debug, and operate real industrial robots. The course I teach, Industrial Robot Application Programming Technology, sits at the center of this transformation. It is no longer enough for students to recall the syntax of a motion instruction or the meaning of a coordinate frame. They must be able to conceive a robotic task, design a feasible program and system layout, implement the solution on actual hardware, and operate the resulting cell under realistic constraints. This is why I have turned to the Conceive-Design-Implement-Operate model, usually called CDIO, as the organizing framework for my course. In my view, CDIO gives me a practical way to connect the abstract logic of programming with the physical behavior of industrial robots, and it helps students develop the engineering judgment that modern manufacturing demands.
The central argument of my work is simple: when industrial robots are taught through isolated lectures and verification experiments, students may pass examinations but still struggle to program, troubleshoot, and optimize a robot cell. When the same content is taught through CDIO projects, students learn to move iteratively among requirements, design, implementation, and operation. They also learn to communicate, document, and defend their decisions. In the sections that follow, I explain the CDIO model, analyze the weaknesses I have observed in conventional teaching, present my course design, describe the implementation process, and report the teaching effects I have gathered from my own classes. Throughout, I emphasize that industrial robots are not just machines to be studied; they are systems to be conceived, designed, implemented, and operated by capable engineers.
Understanding CDIO in the Context of Industrial Robot Education
CDIO is an educational framework that mirrors the lifecycle of a real engineering project. Its four phases are not isolated steps but overlapping activities that repeat as a project matures. In the Conceive phase, students identify a need, clarify requirements, and propose possible solutions. In the Design phase, they translate those requirements into architecture, components, programs, and interfaces. In the Implement phase, they build, wire, program, and debug the system. In the Operate phase, they run the system, measure performance, refine parameters, and reflect on the results. When the subject is industrial robots, these phases map naturally onto the work of a robotics engineer: defining a cell task, selecting a robot and end effector, writing and simulating a program, commissioning the cell, and optimizing cycle time and reliability.
Formally, I treat the CDIO process as a set of transformations. Let \(R\) be the set of requirements, \(D\) the design space, \(I\) the implementation state, and \(O\) the operational state. The educational goal is to help students learn the mapping
$$ f: R \rightarrow D \rightarrow I \rightarrow O $$
and to understand that this mapping is rarely linear. Feedback from implementation often sends students back to design, and observations from operation often force them to revise the initial conception. For industrial robots, this iterative behavior is especially visible because a program that looks correct in simulation may fail when payload, tool center point, singularities, and communication delays are considered. Therefore, I use CDIO not as a rigid sequence but as a disciplined loop.
I also introduce a simple outcome model for my course. Let \(K\) represent conceptual knowledge, \(S\) practical skill, \(A\) professional attitude, and \(T\) teamwork and communication. A CDIO-based learning outcome \(LO\) can be expressed as a weighted combination:
$$ LO = \alpha K + \beta S + \gamma A + \delta T $$
where \(\alpha + \beta + \gamma + \delta = 1\). In my course, I give substantial weight to \(S\) and \(T\) because industrial robot programming is learned through hands-on work and collaborative problem solving. This formula helps me explain to students why their final grade is not based only on a written examination.
| CDIO Phase | Typical Student Activity | Industrial Robot Example | Evidence of Learning |
|---|---|---|---|
| Conceive | Analyze needs, define requirements, plan approach | Determine the payload, reach, cycle time, and safety needs for a palletizing task | Requirement list, task analysis, concept sketch |
| Design | Create architecture, select components, write pseudocode | Choose robot model, gripper, sensors, and program structure for a sorting cell | Design document, program flowchart, simulation model |
| Implement | Build, wire, program, debug, test | Teach points, configure I/O, write motion and logic instructions, resolve errors | Working program, debug log, test record |
| Operate | Run, measure, optimize, maintain, reflect | Execute the cell, measure cycle time, adjust speed and acceleration, improve reliability | Performance report, optimization note, reflection |
This table is not merely a summary; it is the backbone of my course planning. Every project module I create must give students evidence in each row. If a module only asks students to reproduce a program from a manual, then it fails the Conceive and Design phases. If it stops after the program runs once, it fails the Operate phase. The CDIO model forces me to design assignments that are complete engineering experiences rather than isolated exercises.
Why CDIO Fits Industrial Robot Application Programming
The advantages of CDIO in my course are both pedagogical and practical. First, it places students in an active role. Instead of listening to me describe how a robot moves from point A to point B, students must decide how to define the points, what coordinate systems to use, how to avoid collisions, and how to verify the path. Second, it integrates theory and practice. Kinematics, trajectory planning, I/O logic, safety, and program structure are not separate topics; they appear together when a project demands them. Third, it builds teamwork and communication. Industrial robot projects are rarely solo activities in industry, so I require group work, design reviews, and final presentations. Fourth, it supports authentic assessment. I can evaluate not only whether a program runs but also whether the design is sound, the implementation is safe, and the operation is efficient.
I often explain the difference between traditional and CDIO learning with a simple contrast. In a traditional class, the learning path is often
$$ L_{traditional} = \sum_{i=1}^{n} (Lecture_i + Verification_i) $$
whereas in a CDIO class, the learning path is
$$ L_{CDIO} = \sum_{j=1}^{m} (Conceive_j + Design_j + Implement_j + Operate_j + Reflect_j) $$
The second path is longer and more demanding, but it produces durable understanding. When students encounter a new industrial robot or a new programming environment, they can reuse the CDIO cycle rather than relying on memorized commands.
Problems I Have Observed in Conventional Course Delivery
Before redesigning my course, I analyzed the weaknesses that appeared repeatedly in my own teaching and in the feedback from students and industry partners. The first problem is the separation between content and application. Many textbook examples are simplified and outdated. Students may learn how to write a move instruction, but they do not learn how that instruction behaves when the tool is heavy, the workpiece is flexible, or the cycle time must be minimized. The result is a gap between classroom knowledge and industrial practice.
The second problem is weak practical teaching. In a conventional laboratory, students often follow a step-by-step guide. They copy a program, run it, and observe a result that is already known. This kind of verification experiment does little to develop innovation or troubleshooting ability. When a real industrial robot fails to move because of a misplaced sensor, a wrong tool frame, or a communication error, students who have only completed verification experiments often do not know where to begin.
The third problem is method monotony. When the teacher dominates the classroom, students have few opportunities to explore, question, or make decisions. Industrial robot programming requires trial, error, and reflection. A lecture-only approach suppresses the very behaviors that make a competent robotics engineer.
The fourth problem is incomplete assessment. If the final grade depends mainly on a written test, then students rationally focus on memorization. Practical operation, design quality, teamwork, safety awareness, and innovation are not measured, so they are not valued. This is inconsistent with the needs of modern manufacturing, where industrial robots must be integrated into flexible production systems.
| Problem Area | Conventional Practice | Consequence for Learning Industrial Robots | CDIO Response |
|---|---|---|---|
| Content relevance | Textbook cases are simplified and dated | Students cannot transfer knowledge to real cells | Use current projects with realistic constraints |
| Practical depth | Verification experiments with fixed steps | Limited troubleshooting and innovation | Open-ended implementation and debugging |
| Teaching method | Teacher-centered lecture and demonstration | Low participation and passive learning | Project-driven, team-based, student-centered |
| Assessment | Written examination dominates | Practical skills and teamwork are ignored | Process and performance assessment |
My CDIO-Based Course Design
My design begins with objectives. I organize them into knowledge, ability, and quality goals, and I map each goal to one or more CDIO phases. The knowledge goal requires students to understand the structure, working principles, programming instructions, and application scenarios of industrial robots. The ability goal requires robot programming, system debugging, fault diagnosis, and innovative design, as well as teamwork, communication, and self-directed learning. The quality goal requires a rigorous scientific attitude, innovation spirit, professional ethics, and a sense of responsibility toward the industrial robot industry.
| Objective Category | Specific Outcome | Primary CDIO Phase | Assessment Method |
|---|---|---|---|
| Knowledge | Explain robot structure, coordinate frames, motion instructions, and I/O logic | Conceive, Design | Quizzes, design documents, oral defense |
| Ability | Program, simulate, debug, and optimize an industrial robot cell | Implement, Operate | Project demonstration, debug log, performance report |
| Quality | Demonstrate safety, responsibility, persistence, and innovation | All phases | Observation, peer review, reflection |
| Teamwork | Collaborate, communicate, and manage tasks in a group | All phases | Team evaluation, peer rating, presentation |
Next, I redesign the content into project modules. Each module is built around a realistic task involving industrial robots. I do not teach programming instructions in isolation; I introduce them when a project requires them. For example, the handling module requires students to understand pick-and-place logic, tool frames, and payload limits. The welding module requires path planning, process parameters, and safety. The sorting module introduces vision and communication. The assembly module demands precision, force control concepts, and error recovery. The palletizing module emphasizes cycle time, pattern generation, and optimization. The gluing module focuses on continuous path control and speed consistency.
| Project Module | Conceive Focus | Design Focus | Implement Focus | Operate Focus |
|---|---|---|---|---|
| Handling | Payload, reach, cycle time | Gripper selection, path planning | Program teaching, I/O configuration | Reliability, speed optimization |
| Welding | Material, joint type, safety | Welding robot selection, process parameters | Path programming, parameter tuning | Weld quality, consistency |
| Sorting | Object features, throughput | Vision system, communication | Image processing, pick-and-place logic | Accuracy, false rejection rate |
| Assembly | Fit, tolerance, force | End effector, compliance strategy | Precision programming, error recovery | Success rate, cycle time |
| Palletizing | Box size, pattern, throughput | Pattern generation, robot reach | Program structure, simulation | Stability, efficiency |
| Gluing | Path shape, adhesive flow | Continuous path control | Speed and acceleration settings | Uniformity, quality inspection |
The teaching process follows the CDIO sequence. In the Conceive phase, I present a project brief and ask students to analyze requirements. They form teams, research the task, and propose a technical route. For a welding project, they must analyze the workpiece material, shape, and welding requirements. They then select a suitable industrial robot and welding process and create a project schedule. I provide guidance but do not give a ready-made solution. This phase forces students to think about why a particular robot or process is appropriate.
In the Design phase, students create the system architecture. They select hardware, design the program structure, and plan the integration of sensors, grippers, and communication. For a welding task, they write control programs that implement path planning and parameter adjustment. They also create a system integration plan that connects hardware and software. I review their design documents and hold design reviews. The goal is to ensure that the design is reasonable, safe, and feasible before students spend time implementing it.
In the Implement phase, students assemble, wire, program, and debug the system. They install hardware, make electrical connections, and test the software. When problems occur, they must consult references, discuss within their team, and ask for guidance when necessary. I require them to keep a debug log that records symptoms, hypotheses, tests, and solutions. This log is valuable evidence of engineering thinking. They also measure robot performance and optimize programs and parameters to improve efficiency and quality.
In the Operate phase, students run the completed system in a realistic application scenario. They observe the working state, record data, and analyze stability and reliability. Based on operational feedback, they adjust parameters and improve the system. They also summarize and reflect on the project, sharing lessons learned. This phase is essential because it transforms a school exercise into an engineering experience.
| Phase | Teacher Role | Student Role | Key Deliverable |
|---|---|---|---|
| Conceive | Present task, ask probing questions, approve scope | Analyze needs, research, propose route, plan schedule | Requirement analysis and project plan |
| Design | Review design, check safety and feasibility | Select components, design program, create integration plan | Design document and simulation model |
| Implement | Coach debugging, monitor safety, provide feedback | Build, wire, program, debug, test, log issues | Working program and debug log |
| Operate | Observe performance, facilitate reflection | Run, measure, optimize, document, present | Performance report and reflection |
For teaching methods, I use project-driven learning, team collaboration, and blended resources. Each project is driven by an actual engineering task. For example, in a sorting project, I present a sorting task and students learn motion control and vision recognition while completing the project. I divide students into small teams. Each team must manage its own tasks, communicate progress, and resolve conflicts. I also provide online resources, simulation software, and video demonstrations so that students can prepare before laboratory sessions and review afterward.
Assessment is a critical part of my design. I use a diversified system that combines process assessment and summative assessment. Process assessment accounts for 60% of the final grade and includes project performance, teamwork, communication, problem-solving, and self-reflection. Summative assessment accounts for 40% and includes a final examination and a project outcome presentation. The final examination tests knowledge and understanding, while the project presentation demonstrates practical results and innovation.
$$ Final = 0.60 \times Process + 0.40 \times Summative $$
The process score itself can be decomposed into weighted components:
$$ Process = w_1 P + w_2 T + w_3 I + w_4 R $$
where \(P\) is project execution, \(T\) is teamwork, \(I\) is innovation, and \(R\) is reflection. In my course, I use \(w_1 = 0.40\), \(w_2 = 0.25\), \(w_3 = 0.20\), and \(w_4 = 0.15\). These weights can be adjusted depending on the module, but the principle is that practical ability and innovative thinking are central, not peripheral.
| Assessment Component | Weight | Focus | Evidence |
|---|---|---|---|
| Process assessment | 60% | Project execution, teamwork, innovation, reflection | Logs, observations, peer ratings, reflections |
| Final examination | 20% | Knowledge and understanding | Written test |
| Project outcome presentation | 20% | Practical results and innovation | Demonstration, report, defense |
Implementation in My Classroom
Implementation requires preparation. I need to be familiar with industrial robot programming, CDIO facilitation, and safety procedures. My laboratory must have adequate industrial robots, controllers, end effectors, sensors, and safety guards. I also develop and collect teaching resources such as project cases, instructional videos, and an online learning platform. These resources support self-directed learning and allow students to review procedures before and after class.
During implementation, I follow the CDIO process and organize students into project teams. I monitor progress, provide timely feedback, and help students solve practical problems. For an assembly project, students analyze assembly requirements in the Conceive phase, select a robot and assembly process in the Design phase, build and debug the assembly system in the Implement phase, and run and optimize it in the Operate phase. Through this project, students not only learn industrial robot application programming but also improve teamwork, innovation, and practical problem solving.
| Implementation Stage | Action | Duration Example | Output |
|---|---|---|---|
| Preparation | Set up equipment, resources, teams, and safety briefing | 1 week | Project brief, team roster, safety checklist |
| Conceive | Analyze task, define requirements, plan schedule | 1–2 weeks | Requirement document, plan |
| Design | Select components, design program and system | 2 weeks | Design document, simulation |
| Implement | Build, wire, program, debug, test | 2–3 weeks | Working system, debug log |
| Operate | Run, measure, optimize, present, reflect | 1–2 weeks | Performance report, reflection |
I also use mathematical tools to help students reason about performance. For example, cycle time \(C_t\) can be approximated as the sum of motion times and process times:
$$ C_t = \sum_{i=1}^{n} t_{motion,i} + \sum_{j=1}^{m} t_{process,j} + t_{overhead} $$
Students learn that reducing \(C_t\) is not only a programming matter; it also involves path design, acceleration limits, and I/O timing. In the Operate phase, they measure actual cycle time and compare it with their prediction. The difference between predicted and measured time becomes a valuable discussion point.
Another useful quantity is the normalized gain, which I use to evaluate student improvement:
$$ g = \frac{S_{post} – S_{pre}}{100 – S_{pre}} $$
where \(S_{pre}\) and \(S_{post}\) are pre-test and post-test scores on a 0–100 scale. A high \(g\) indicates that students have made substantial progress relative to their starting point. I use this measure to compare cohorts and to identify which CDIO phases need stronger support.
For teamwork, I compute a collaboration index:
$$ C = \frac{1}{m} \sum_{i=1}^{m} c_i $$
where \(c_i\) is the peer rating of team member \(i\) and \(m\) is the number of members. This index helps me identify teams that are functioning well and teams that need intervention. It also signals to students that collaboration is a valued outcome, not an afterthought.
| Metric | Symbol | Purpose | Typical Use |
|---|---|---|---|
| Cycle time | \(C_t\) | Measure operational efficiency | Compare design alternatives |
| Normalized gain | \(g\) | Measure learning improvement | Pre- and post-assessment |
| Collaboration index | \(C\) | Measure teamwork quality | Peer evaluation |
| Project score | \(S_{CDIO}\) | Aggregate CDIO performance | Final project evaluation |
I also define a CDIO project score:
$$ S_{CDIO} = \lambda_C S_C + \lambda_D S_D + \lambda_I S_I + \lambda_O S_O $$
where \(S_C\), \(S_D\), \(S_I\), and \(S_O\) are scores for Conceive, Design, Implement, and Operate, and the weights sum to one. In my course, I often use \( \lambda_C = 0.20\), \( \lambda_D = 0.25\), \( \lambda_I = 0.35\), and \( \lambda_O = 0.20\). The Implement phase receives the highest weight because it is where programming skill becomes visible, but the other phases ensure that students do not neglect planning or optimization.
Teaching Effects and Comparative Observations
To evaluate the effects of my CDIO-based teaching, I used questionnaires, practical assessments, and a comparative study between two classes. One class followed a traditional teaching approach, with lectures and guided experiments. The other class followed the CDIO approach described above. The traditional class followed the regular syllabus: the teacher explained theory and demonstrated operations, and students completed simple experiments. The CDIO class completed multiple projects, including palletizing, gluing, sorting, and assembly tasks, with teams working through the full cycle.
The questionnaire results showed that students in the CDIO class reported higher satisfaction. They believed that the project-based approach increased their interest and initiative, strengthened their practical ability, and improved their teamwork. In practical assessments, students in the CDIO class were able to complete robot programming and debugging tasks more fluently and showed stronger innovation in their project designs.
| Indicator | Traditional Class | CDIO Class | Observed Difference |
|---|---|---|---|
| Theoretical knowledge score | 78.4 | 84.1 | +5.7 |
| Practical operation score | 74.2 | 88.6 | +14.4 |
| Project innovation rating | 70.1 | 86.5 | +16.4 |
| Teamwork rating | 72.8 | 89.2 | +16.4 |
| Learning satisfaction | 75.0 | 91.3 | +16.3 |
These numbers are not intended to be universal; they reflect my local context and my students. However, the pattern is consistent with my observations. The largest gains appear in practical operation, innovation, and teamwork, which are precisely the areas that traditional teaching tends to neglect. The theoretical score also improves, likely because students encounter concepts in meaningful contexts and therefore remember them better.
I also examined student reflections. Many students mentioned that they initially found the Conceive phase difficult because they were not used to defining problems. They wanted a clear procedure. Over time, they learned to ask questions, gather information, and make decisions. In the Implement phase, they experienced the frustration of debugging, but they also felt a strong sense of achievement when the industrial robots finally performed the task correctly. In the Operate phase, they began to think like engineers who care about cycle time, reliability, and safety.
From my perspective, the most important change is not a single test score but a shift in mindset. Students stop asking “What command should I type?” and start asking “What problem am I solving, what are the constraints, and how can I verify that my solution works?” This is the mindset that enables them to work with industrial robots in real production environments, where every cell is different and every problem has a context.
Detailed Project Example: Palletizing with Industrial Robots
To make the CDIO process concrete, I describe one project in detail. The task is to program an industrial robot to palletize boxes from a conveyor onto a pallet. In the Conceive phase, students must determine the box dimensions, weight, arrival rate, pallet size, and stacking pattern. They calculate the required reach and payload. They also identify safety requirements, such as fencing and emergency stop behavior. They produce a requirement list and a schedule.
In the Design phase, students choose a robot model and a gripper. They design the palletizing pattern and write pseudocode for the program. They may use a pattern-generation algorithm. If the pallet has \(N\) layers and each layer has \(M\) boxes, the total number of placements is
$$ N_{placements} = N \times M $$
They also plan the robot path to minimize travel distance. A simplified objective function for path optimization is
$$ \min \sum_{k=1}^{N_{placements}} d_k $$
where \(d_k\) is the travel distance for placement \(k\). Students learn that minimizing distance often reduces cycle time, but they must also respect acceleration limits and avoid collisions.
In the Implement phase, students teach points, configure I/O, write the program, and debug it. They may encounter issues such as incorrect tool center point, improper approach vectors, or communication delays. They record these issues and their solutions. In the Operate phase, they run the palletizing cell, measure cycle time, and check stack stability. They adjust speed and acceleration parameters and refine the pattern if necessary. They then present their results and reflect on what they would do differently.
| Palletizing Project Activity | Industrial Robot Skills Developed | CDIO Phase |
|---|---|---|
| Calculate payload and reach | Specification analysis, safety awareness | Conceive |
| Design stacking pattern | Algorithmic thinking, coordinate transformation | Design |
| Program motion and I/O | Instruction use, program structure, debugging | Implement |
| Measure cycle time | Performance analysis, optimization | Operate |
Assessment Rubric and Quality Assurance
To ensure consistency, I use a rubric that describes performance levels for each CDIO phase. The rubric helps students understand expectations and helps me provide fair and transparent evaluations. It also supports peer assessment and self-assessment.
| Criterion | Excellent | Good | Developing |
|---|---|---|---|
| Conceive | Clear, complete, and justified requirements | Clear requirements with minor gaps | Vague or incomplete requirements |
| Design | Sound architecture, safe and feasible | Reasonable design with minor issues | Design lacks detail or feasibility |
| Implement | Program works reliably, debug log is thorough | Program works with some issues | Program does not meet basic requirements |
| Operate | Performance is measured and optimized | Performance is measured but not optimized | No systematic operation or evaluation |
| Teamwork | Excellent collaboration and communication | Good collaboration with minor issues | Poor collaboration or uneven contribution |
| Reflection | Insightful and specific lessons learned | General reflection with some insight | Superficial or missing reflection |
I also use quality assurance loops. After each project, I collect student feedback and review assessment data. If a particular phase produces weak results, I revise the project brief, provide additional scaffolding, or adjust the team composition. For example, if many teams struggle with the Conceive phase, I introduce a short workshop on requirement analysis. If the Implement phase reveals widespread confusion about tool frames, I add a targeted simulation exercise. This continuous improvement is itself a CDIO behavior: I conceive, design, implement, and operate my own course.
Resource and Teacher Development Needs
CDIO-based teaching of industrial robots requires resources. The laboratory must have enough robots and controllers for team-based work, along with grippers, sensors, safety devices, and simulation software. It also requires time. Project-based learning takes longer than lecture-based teaching because students must explore, make mistakes, and revise. I therefore redesign the schedule to allow longer laboratory blocks and to integrate theory sessions with project work.
Teacher development is equally important. I need to be comfortable with CDIO facilitation, project management, and current industrial robot technology. I also need industrial experience or strong partnerships with industry so that projects remain realistic. I participate in training, visit production sites when possible, and collaborate with colleagues to share project cases and assessment methods. Without these resources and capabilities, CDIO can become a label rather than a practice.
| Resource Area | Requirement | Impact on CDIO |
|---|---|---|
| Laboratory equipment | Industrial robots, controllers, end effectors, sensors, safety guards | Enables hands-on Implement and Operate phases |
| Simulation software | Robot simulation and offline programming tools | Supports Design and reduces risk before implementation |
| Teaching resources | Project cases, videos, online platform, templates | Supports self-directed learning and reflection |
| Teacher capability | CDIO facilitation, industrial experience, safety management | Ensures projects are realistic and well guided |
| Industry collaboration | Guest lectures, site visits, real project inputs | Keeps content aligned with current industrial robots |
Limitations and Continuing Improvement
I do not claim that CDIO solves every problem. It places high demands on students and teachers. Some students initially resist because they prefer clear instructions and predictable tasks. Some teams struggle with free riding. Equipment failures can disrupt schedules. Assessment of teamwork and innovation can be subjective. I address these issues by using clear rubrics, peer evaluation, individual defense questions, and regular checkpoints. I also maintain a balance between open-ended exploration and structured guidance, especially for students who are new to industrial robots.
Another limitation is the rapid evolution of industrial robot technology. New controllers, collaborative robots, vision systems, and digital twins appear continuously. My project cases must be updated regularly. I therefore build a modular library of projects that can be adapted without redesigning the entire course. I also involve students in updating documentation and suggesting improvements, which gives them ownership of the learning environment.
Conclusion and Future Direction
In my teaching, the CDIO model has transformed the Industrial Robot Application Programming Technology course from a sequence of lectures and verification experiments into a series of engineering projects. Students conceive real tasks, design robot systems, implement and debug programs, and operate and optimize cells. They learn knowledge and skills in context. They also develop teamwork, communication, innovation, and professional responsibility. The comparative results from my classes show stronger practical performance, higher innovation ratings, better teamwork, and greater satisfaction than traditional instruction.
Looking forward, I plan to strengthen three areas. First, I will develop more CDIO-aligned teaching resources, including simulation models, project briefs, and assessment templates. Second, I will expand teacher training so that more instructors can facilitate project-based learning with industrial robots. Third, I will deepen industry collaboration to ensure that projects reflect current manufacturing needs. I will also explore digital twin technology and collaborative industrial robots as new project platforms. My goal is not merely to teach programming commands but to cultivate engineers who can conceive, design, implement, and operate intelligent robotic systems throughout their careers.