Teaching Robotics in Kyrgyzstan: What I Learned Building a Robotics Club from the Ground Up

By Ahmed Elmalla | ICT & Computer Science Teacher

When people see students working with a robot, the finished machine naturally gets most of the attention.

The wheels move. The robot turns. Students press buttons and watch their instructions become physical actions. From the outside, a school Robotics Club can look like a straightforward combination of an educational robot kit, some programming and enthusiastic students.

My experience teaching robotics in Kyrgyzstan has been much less straightforward—and much more interesting.

I have been discovering that creating a meaningful school robotics program isn't simply a matter of purchasing robotics equipment and handing it to students. There are technical problems, curriculum decisions, differences in students' cognitive readiness, competition from other extracurricular activities, parent expectations and the challenge of maintaining interest as students become older.

I have also had to learn alongside my students.

For one of our projects, I built a base-car robot model and started developing the block-based code needed to control it. The materials available to me for the robotics equipment did not simply give me the complete movement code I needed. I had to search for videos, understand the programming environment, experiment with different blocks and gradually build the movement logic myself.

The program eventually grew beyond simply telling the robot to move forward. I began working with yaw-angle feedback, movement correction and controlled left and right turns.

That process taught me something important about teaching robotics:

Before I could teach students how to solve these problems, I had to become the learner myself.

At the same time, another challenge was developing outside the code.

Some younger students were extremely interested in joining but were not yet cognitively ready for the type of robotics work I wanted the club to do. Some Year 7 students who joined eventually moved toward Chinese, Debate Club or other activities, sometimes following parental advice. Students from Year 8 upward, meanwhile, have rarely demonstrated the level of interest in programming and robotics that I initially expected.

These experiences have made me rethink what robotics education actually requires.

This article begins a series in which I want to document that experience honestly: what I build, what works, what doesn't, how students respond, what parents think, how age affects readiness and what I learn as I continue developing robotics education in Kyrgyzstan.

Why I Want to Document My Experience Teaching Robotics in Kyrgyzstan

There are already thousands of articles explaining the benefits of robotics.

Robotics develops problem-solving.

Robotics supports STEM.

Robotics encourages creativity.

Robotics can teach programming.

I agree with many of those ideas, but repeating them doesn't tell another teacher what actually happens when you try to establish a Robotics Club in a real school.

The interesting questions begin after the promotional language ends.

What happens when the equipment arrives but you don't have the exact code you need?

What happens when the teacher is still learning the robotics platform?

What happens when a Grade 2 student desperately wants to participate but cannot yet follow the sequence of reasoning required to debug a robot?

What happens when a capable Year 7 student leaves because another extracurricular activity becomes a higher priority?

And what happens when the older students you expected to be most interested in programming aren't particularly interested at all?

Those are the questions I want this series to explore.

I teach ICT and Computer Science, so programming and computational thinking are already part of my educational world. Robotics, however, adds another layer.

When software fails, you investigate software.

When a robot fails, the problem might be software—but it might also be hardware, movement, orientation, construction, calibration or the interaction between several systems.

That complexity is exactly what makes robotics valuable.

It is also what makes teaching it challenging.

Starting with a Robot Kit Was Only the Beginning

Educational robotics kits can create the impression that the equipment itself is the curriculum.

Open the box.

Build the model.

Load the program.

Watch the robot move.

But I quickly discovered that owning robotics hardware and knowing how to turn that hardware into a structured learning experience are very different things.

The kit gives you components.

The teacher still needs to create the learning journey.

For me, this meant understanding how I wanted students to progress.

Should we begin with construction?

Should students first understand motors?

When should programming appear?

Do I provide the code?

Should students modify my code?

At what point should they create their own?

How much mathematics do they need before movement correction makes sense?

These questions don't arrive neatly packaged with the robot.

The teacher has to answer them.

That has made the project as much about curriculum design as robotics.

Building My First Base-Car Model

One of the important steps in developing the club was constructing a base-car model.

A base car sounds simple.

You need a platform capable of moving forward and turning.

But even this basic objective quickly introduces several layers of engineering and Computer Science.

The physical robot needs to be assembled correctly.

The motors need to respond as expected.

The programming environment needs to communicate with the robot.

Then movement needs to become predictable enough that students can actually build more complex behaviours on top of it.

If I tell the robot to turn left, I don't merely want it to move vaguely toward the left.

Eventually I want to reason about the turn.

Can it turn approximately 90 degrees?

Can I measure the orientation?

Can I stop the movement when the desired orientation has been reached?

Those questions pushed the project from simple motor control toward feedback-based movement.

From Mechanical Construction to Controlled Movement

This transition is important for students.

Building the car is satisfying because they can physically see progress.

But construction is only the beginning.

A robot becomes much more interesting when students understand that physical behaviour can be represented through an algorithm.

For example:

Start → Move forward → Stop → Turn right → Stop

Then we can ask:

How far forward?

How does the robot know that it has turned 90 degrees?

What happens if the wheels behave slightly differently?

What happens if we repeat the same command several times?

The physical model creates a platform for asking computational questions.

And that is where the project becomes much more than assembling parts.

The Challenge I Did Not Expect: Where Is the Code?

One challenge surprised me.

I expected that once I had the robotics equipment, getting started with the programming side would be relatively straightforward.

It wasn't.

For the CNC and LEGO-related robotics equipment and materials I was working with, I did not have ready-made code covering the particular movement behaviours I wanted to implement.

That meant I had to learn.

This is an important distinction because I don't want to suggest that no documentation or educational material exists for these platforms. My experience was simply that the resources available to me did not provide a complete program I could take and immediately use for my base-car objectives.

So I did what many programmers do when documentation doesn't answer the immediate problem.

I searched.

I watched videos.

I examined examples.

I tested blocks.

I made mistakes.

Then I tried again.

Ironically, the process I wanted students to learn through Robotics Club was exactly the process I had to follow myself.

Learning the Block Programming Environment Myself

Block programming sometimes receives an unfair reputation for being “easy” because students aren't typing traditional syntax.

But removing syntax doesn't remove logic.

The program I developed for the robot car demonstrates this clearly.

There are events.

There are custom blocks.

There are parameters.

There is selection.

There is repetition.

There are variables.

There is sensor feedback.

There are Boolean conditions.

There is correction logic.

That's programming.

The visual blocks simply represent the instructions differently.

As I became more comfortable with the environment, I began moving from isolated movement commands toward reusable behaviours.

Instead of rebuilding the same sequence repeatedly, I could define blocks such as:

MoveForward

Left90

Right90

and then call those behaviours when needed.

This starts introducing students to one of the most important ideas in Computer Science: abstraction.

YouTube, Experimentation and a Lot of Debugging

Video tutorials helped me understand how other people approached the platform, but watching someone else's solution isn't the same as understanding your own robot.

Eventually you have to experiment.

Change a value.

Run the robot.

Observe.

Change it again.

At times, the robot itself becomes the debugging output.

If it turns too far, something needs adjustment.

If it doesn't reach the expected angle, investigate.

If forward movement drifts, think about correction.

This is one reason I believe teachers shouldn't feel embarrassed about learning from videos or tutorials while developing a robotics program.

Computer Science teachers cannot already know every platform, programming environment and piece of hardware they will encounter.

What matters is demonstrating the ability to learn independently and turn that learning into teachable knowledge.

Building My Own Movement Blocks

The block-code program accompanying this article represents part of that learning process.

Rather than leaving movement as disconnected instructions, I began creating reusable movement behaviours.

My MoveForward block contains logic for different movement approaches. The program sets movement speed and motor configuration and also contains a correction branch using orientation information.

I also created separate Left90 and Right90 behaviours.

The turning logic resets the yaw angle, starts the movement and then waits for the yaw measurement to reach the desired range before stopping.

That matters educationally.

A command such as:

“Turn right for one second.”

doesn't actually mean:

“Turn exactly 90 degrees.”

The result depends on the robot.

Feedback gives us a better question:

“Continue turning until the measured orientation reaches our target.”

Now students can begin seeing the difference between controlling something through time and controlling it using feedback.

That opens a much richer engineering conversation.

Why Yaw Feedback Changed the Robot Car

The screenshot from my project shows one of the concepts I want students eventually to understand: using the robot's yaw angle as feedback.

For the right turn, the program resets yaw to zero, begins turning and waits until the yaw angle passes the target threshold before stopping.

The left-turn block uses the corresponding negative orientation.

The thresholds in my current code are around ±90 degrees, with values such as greater than 89 or less than -89 used to decide when movement should stop.

This is much more interesting than memorizing a block.

Students can ask:

Why 89?

Why reset yaw first?

What happens if we use 80?

What happens if the robot overshoots?

Does the same threshold always produce exactly the same physical result?

Those are experimental questions.

And now programming, Mathematics and engineering begin meeting in the same activity.

From Timed Movement to 90-Degree Turns

This progression also creates a useful teaching sequence.

At the beginner level, students can make the robot move.

Then they can make it stop.

Then they can make it turn.

After that, the question becomes:

Can we make the turn more precise?

Now introduce orientation.

Then:

Can we compensate when movement isn't straight?

Now introduce correction.

Eventually:

Can we combine these behaviours to navigate a path?

That is how I want the club to develop—not as isolated tricks, but as a sequence in which one engineering problem creates the need for the next Computer Science concept.

Suggested Image Placement — Actual Code Screenshot

Place the uploaded block-code screenshot here.

Caption:
Part of the block-based control program I developed for the base-car model. The program includes forward movement, movement correction and 90-degree left/right turns using yaw-angle feedback.

Alt text:
Block programming code developed by Ahmed Elmalla for a school robotics car using yaw angle correction and 90 degree turns

Teaching Students That Robotics Is More Than Assembling a Kit

This distinction has become increasingly important to me.

A student can assemble a robotics model by following instructions without necessarily understanding robotics deeply.

The real learning begins when we ask:

Why does it work?

Then:

Can you change it?

Then:

Can you fix it when it stops working?

And eventually:

Can you design your own solution?

That's the progression I want.

Assemble → Understand → Modify → Debug → Design

If students only reproduce a model exactly, they may develop useful construction skills, but we're leaving a lot of Computer Science and engineering potential untouched.

I want them eventually to look at my Left90 block and understand why the condition exists.

I want them to question my correction logic.

I want them to change values and predict the consequences.

And eventually I want them to tell me:

“Sir, I think there's a better way to do this.”

At that point, the club has become much more interesting.

The Parent Challenge: Not Everyone Sees Robotics the Same Way

One of the biggest lessons I've learned has nothing to do with motors or code.

Students do not choose extracurricular activities in isolation.

Parents naturally influence those decisions.

I have had Year 7 students leave robotics for activities such as Chinese language learning or Debate Club, whether because of parental advice, competing interests or other extracurricular priorities.

I don't think the right response is to say those parents are wrong.

Chinese can be extremely valuable.

Debate can be extremely valuable.

Sports, music, languages and other activities can all develop important skills.

The real issue is that families have limited time.

A student cannot realistically participate in everything.

Robotics therefore competes for time with activities whose benefits parents may understand more immediately.

The value of learning Chinese is easy to communicate.

The value of debate is relatively visible.

Robotics can be misunderstood as:

“Students playing with robot toys after school.”

If that's how parents see it, we have a communication problem.

The teacher needs to show what is actually happening behind the moving car:

Programming.

Mathematics.

Engineering.

Problem-solving.

Debugging.

Collaboration.

Persistence.

The robot is the visible product.

The thinking behind it is the real curriculum.

When Students Choose Chinese, Debate or Other Activities Instead

I think this deserves discussion without becoming defensive about robotics.

A successful school should offer students different opportunities.

The question isn't:

“How do I stop students choosing Debate Club?”

The better question is:

“How do I make the educational value of Robotics Club clear enough that students and parents can make an informed choice?”

Part of the answer may be better communication.

Instead of advertising:

Robotics Club — Build Robots!

perhaps we should explain:

Students will learn to design algorithms, program movement, work with sensors, solve mechanical problems, debug systems and collaborate on engineering projects.

Show parents the code.

Show them the engineering notebook.

Show them the failed prototype and the improved prototype.

Show them what the student can explain after six weeks that they couldn't explain before.

In other words, make the learning visible.

Grade 2 Students Want Robotics—But Enthusiasm Is Not the Same as Readiness

At the other end of the age range, I have encountered almost the opposite problem.

Some Grade 2 students are extremely interested in robotics.

They see the robots and immediately want to join.

That enthusiasm is wonderful.

But enthusiasm and readiness are not necessarily the same thing.

The robotics activities I am developing require students to follow multi-stage instructions, understand cause and effect, maintain attention across a build, reason about sequences, interpret feedback and debug when the first attempt fails.

Some younger students may not yet have the cognitive maturity required for that level of independence.

That doesn't mean young children shouldn't experience robotics.

It means the robotics curriculum needs to match their developmental stage.

A Grade 2 robotics experience may need to emphasize:

simple sequencing;

direction;

cause and effect;

basic construction;

short challenges;

visual programming;

immediate feedback.

Asking those students to work with the same abstraction and debugging expectations as older students would be unfair.

This has made me increasingly interested in the question:

What is the right robotics curriculum for each age?

That deserves its own article in this series.

Year 7 Seems to Be an Interesting Middle Ground

Based on my experience so far, Year 7 is particularly interesting.

Students at this age can often handle significantly more abstraction than very young learners while still retaining strong curiosity about building physical things.

They can begin understanding why an algorithm works.

They can work with variables and conditions.

They can follow more complicated build sequences.

They can begin debugging rather than immediately asking the teacher to solve everything.

At the same time, this is also an age when extracurricular choices begin multiplying.

Students may have languages, sports, debate, academic clubs and other commitments.

So technical readiness does not guarantee retention.

That's an important distinction.

A student may be perfectly suited to robotics academically and still decide that another activity matters more.

A sustainable Robotics Club therefore needs more than an appropriate curriculum.

It needs a reason for students to keep coming back.

Why Year 8 and Older Students Rarely Show the Same Interest

One observation that has surprised me is the relatively limited interest I have seen from Year 8 and older students in programming and robotics.

I don't want to overgeneralize this into a claim about all teenagers in Kyrgyzstan. This is an observation from my own teaching context so far, and different schools may see very different patterns.

Still, it raises an important question.

Why might older students be less interested?

Perhaps beginner robotics looks childish to them.

Perhaps academic pressure increases.

Perhaps they already have established extracurricular interests.

Perhaps the projects don't yet feel advanced or relevant enough.

Perhaps students need to see a clearer connection between robotics and careers such as engineering, software development, automation, electronics or artificial intelligence.

Or perhaps the challenge needs to change.

A Year 6 student may be excited because:

“I made the robot move!”

A Year 9 student may need:

“Can you make this autonomous system solve a real problem?”

Those are very different motivational levels.

I don't yet have a definitive answer.

And I think saying “I don't know yet” is valuable.

That's one of the questions I want this article series to investigate.

What These Age Differences Are Teaching Me

The biggest lesson is that there probably shouldn't be one generic Robotics Club curriculum for everyone.

I am beginning to see at least three potential stages.

For younger learners, robotics should emphasize exploration, sequencing, cause and effect, and playful construction.

For middle-school learners, the balance can move toward structured programming, sensors, movement, algorithms and debugging.

For older students, the projects may need to become substantially more authentic and challenging: autonomous behaviour, engineering design problems, competitions, computer vision, electronics, advanced programming or student-designed projects.

The robot can be the same.

The intellectual challenge cannot.

This is something I want to refine as I gain more experience.

What I Would Change as the Robotics Club Develops

If I were designing the next stage of the club based on what I have learned so far, I would focus on four areas.

First, I would create a clearer progression pathway so students and parents can see where robotics leads.

Not simply:

Week 1: Build this.
Week 2: Build that.

Instead:

Level 1 — Movement

Level 2 — Accurate turning

Level 3 — Sensors

Level 4 — Autonomous decisions

Level 5 — Navigation challenge

Level 6 — Student-designed system

Second, I would make student learning more visible to parents.

Third, I would differentiate activities more clearly by age.

Fourth, I would continue building my own technical understanding rather than relying entirely on ready-made projects.

That last point matters to me.

Building the base-car program myself was harder than simply downloading a completed solution.

But it also meant I had to understand the logic.

That makes me better prepared when a student eventually asks:

“Why?”

Conclusion: Building a Robotics Culture Takes More Than Buying Robots

My experience teaching robotics in Kyrgyzstan is still developing.

I don't want this series to present a finished formula for creating the perfect Robotics Club.

I would rather document the process while it is happening.

I have built a base-car model.

I have had to learn unfamiliar block programming through tutorials, videos, experimentation and debugging.

I have developed movement logic involving forward motion, correction and yaw-based 90-degree turns.

I have watched younger children become fascinated by robots before they are necessarily ready for the full cognitive demands of the activities.

I have seen Year 7 students participate and then move toward Chinese, Debate Club and other priorities.

I have also been surprised by the comparatively limited robotics and programming interest I have observed among older students in my current context.

None of those experiences makes me less convinced that robotics has educational value.

They make me more interested in understanding how to teach it effectively.

Because building a Robotics Club isn't only about buying robots.

It's about building a curriculum.

Building teacher knowledge.

Building student confidence.

Building parent understanding.

Building a progression from curiosity to genuine engineering thinking.

And, perhaps most difficult of all, building a culture in which students see themselves not simply as users of technology, but as people capable of understanding, programming and creating it.

That's the journey I want this Teaching Robotics in Kyrgyzstan series to document.

Frequently Asked Questions About Teaching Robotics in Kyrgyzstan

1. Why am I writing a series about teaching robotics in Kyrgyzstan?

I want to document the practical experience of developing robotics education in my own teaching context, including technical challenges, student engagement, age differences, parent expectations, curriculum development and the process of learning new robotics platforms as a teacher.

2. What did I program for the base-car robot?

My current block-based project includes forward movement, movement correction and separate left/right turning behaviours. The turning blocks use yaw-angle feedback, resetting orientation and stopping when the robot reaches approximately a 90-degree change in direction.

3. What age is best for learning robotics?

My experience so far suggests that the answer depends heavily on the type of robotics activity. Younger students may benefit from simple sequencing and construction, while older students can work with increasingly sophisticated programming, debugging, sensors and engineering problems. This is one of the questions I plan to explore further in this series.

4. Why do some students leave Robotics Club?

In my experience, robotics competes with many worthwhile extracurricular activities. Some students have moved toward Chinese, Debate Club or other activities because of their own interests, parental guidance or competing priorities. This highlights the importance of clearly communicating what students actually learn through robotics.

5. Why might older students show less interest in robotics?

I don't yet have enough evidence to give a definitive answer. In my current context, Year 8 and older students have shown less interest than I expected. Possible explanations include competing academic priorities, established interests and the need for more advanced or authentic projects. I plan to examine this question in a separate article rather than pretending there is one simple explanation.

 

---

Author Bio

Cambridge Computer Science Tutor Author Bio

Ahmed Elmalla is a Computer Science educator, Certified Cambridge International AS & A Level Computer Science (9618) teacher, and software engineer with over 20 years of teaching, software engineering, and international tutoring experience. He specializes in AP Computer Science A (Java) and Cambridge IGCSE (0478) and AS & A Level Computer Science (9618), helping students build strong programming, computational thinking, and exam-solving skills. Through his Learn with Kemo platform, he has mentored students from around the world using practical, exam-focused instruction tailored to each learner's needs. His lessons combine real-world software engineering experience with personalized one-to-one tutoring, making complex Java and Computer Science concepts easier to understand. Ahmed is passionate about helping students gain confidence, improve academic performance, and achieve outstanding results in international Computer Science examinations.

 

LinkedIn: https://www.linkedin.com/in/akelmalla

WhatsApp: https://wa.me/60194028484