Secondary 2 Mobile Robotics preparation depends first on whether the student’s school actually offers a robotics module, approved applied-subject programme or related project. It is not a standard G1 subject taken by every Secondary 2 student, and a child should not assume that a school robotics CCA, introductory coding lesson or classroom model is the same as a national examination course. Ask the school for the actual programme, assessment brief, equipment rules, software, team requirements, practical milestones and safety procedures. Then prepare by learning how a robot receives information, follows instructions, moves, responds to a condition, is tested and is improved.

For parents, the important distinction is between enjoying robotics and being enrolled in a recognised applied subject. SEAB lists Mobile Robotics as MOE–ITE Applied Subject K130 for 2027 school candidates, and explicitly states that these applied subjects are only applicable to candidates from schools approved to offer them; 2027 is the final year of examinations for these MOE–ITE Applied Subjects. A Secondary 2 student may have an introductory school activity, but this does not automatically create a K130 candidature or a universal Sec 2 G1 EOY paper. A useful plan focuses on the real school task, safe practice and the student’s ability to explain how a system works.

• Verify the programme: ask whether the school offers Mobile Robotics as an approved MOE–ITE applied subject, a lower-secondary module, a CCA or a project.
• Confirm the task: collect the syllabus or lesson scope, software, equipment, practical assessment, deadlines and marking rubric.
• Learn the system: identify input, processing, output, movement, sensors, power and control in the robot used at school.
• Practise safely: use only approved kits, batteries, tools, coding platforms and supervised facilities.
• Test methodically: predict behaviour, run one controlled test, record the result, debug and repeat.
• Plan honestly: K130 is a restricted school-approved applied subject and 2027 is its final examination year; check the child’s actual pathway.

First check whether Mobile Robotics is actually available to this student

Mobile Robotics is not a subject that every school offers to every pupil. SEAB’s 2027 G1 school-candidate syllabus page places it under MOE–ITE Applied Subjects and assigns code K130. The page states that these subjects apply only to candidates from schools approved to offer them and that 2027 will be their final year of examinations. The same page lists Smart Electrical Technology K131 and Retail Operations K132 in that applied-subject category. Availability is therefore a formal school matter, not something families can assume from a child’s interest in robots.

A student may take part in a robotics CCA, a STEM enrichment event, a school innovation challenge or a lower-secondary computing lesson without being registered for K130. These are all potentially valuable experiences, but they are not interchangeable qualifications. Ask the school’s subject coordinator or applied-learning lead to identify the exact programme. If it is a CCA, prepare for the club’s project and activity. If it is a curriculum module, follow its class assessment. If it is the recognised applied subject, obtain the official course details and the school’s assessment instructions.

What a robot does: sense, decide and act

A basic robotic system can be understood through three actions: it senses something, processes information and acts. A sensor may detect distance, light, line position or another measurable condition. A controller processes the input according to instructions. A motor or another output device produces an action. This is a simplified model; the exact components depend on the school’s kit and syllabus. The student should be able to identify the real parts they use rather than memorise a generic diagram.

Take a simple line-following robot. A sensor system detects a difference between the surface beneath one side and the other. The controller interprets the readings and adjusts motor behaviour so the robot follows a marked path. The child should explain what information the sensor provides and how the controller uses it. If the robot moves in the wrong direction, the problem may lie in sensor orientation, threshold settings, wiring, code or the surface itself. Understanding the chain makes troubleshooting more systematic.

Inputs, processing and outputs in a robotics task

The input is information entering the system. Processing is the rule or calculation applied to the input. Output is the response. For a distance-sensing robot, the input may be a measured distance. The processing step checks whether an object is closer than a chosen threshold. The output might be to stop or turn. The specific threshold and behaviour should follow the task brief; students should not invent an operating rule and call it the teacher’s requirement.

Ask the child to describe the robot without using vague phrases such as ‘the robot knows’. It receives a sensor reading, the program checks a condition and the motor instruction changes. This language explains what the system does. A parent can help by asking three questions: What does it detect? What rule does it follow? What action happens next? If the student cannot answer one, return to that component and inspect the diagram, code or kit documentation supplied by the school.

Sensors: understand what they measure

Sensors do not understand the world in the way a person does. They provide signals or readings that the system interprets. A distance sensor may estimate how far an object is; a light sensor may measure light intensity; a line sensor may detect differences in reflected light. Different kits use different technology and have different limitations. Follow the manufacturer’s and school’s instructions for the actual component.

Students should avoid claiming that a sensor is perfectly accurate in every environment. Readings may change with surface colour, angle, lighting, distance, power level or other conditions. A robot may behave differently on a dark floor compared with a bright classroom surface if the task uses reflected light. A useful learner asks whether the environment changed and whether the sensor is positioned correctly before changing the entire program.

Motors and movement: link instructions to physical behaviour

Motors convert electrical energy into movement. A robot may use one or more motors to drive wheels, turn a mechanism or move an arm, depending on the kit. The program can control when a motor starts, stops or changes direction, and some systems can adjust speed. Students need to understand the relationship between a command and the observed movement. If a robot turns left when the code says right, check how the motors are mounted and labelled before assuming the software is wrong.

Use a simple paper diagram showing the front of the robot, left and right motor and direction of wheel rotation. Ask the child to predict which way the robot will turn if one wheel moves forward while the other stays still. Then check with a safe school-approved test. A drawing can reveal a misunderstanding before the robot is powered. Avoid asking children to dismantle motors, alter wiring or use batteries outside the kit’s instructions.

Algorithms for a mobile robot

A robot follows a sequence of instructions or a control algorithm. A simple obstacle-response algorithm might be: move forward; read distance; if the object is farther than the threshold, continue; otherwise stop and turn; then read the sensor again. The student should identify the decision condition and the actions for both possible outcomes. The process may repeat until the robot reaches a stop condition. The exact algorithm depends on the project and the teacher’s learning outcomes.

Write the steps in plain language before converting them into a flowchart or blocks. If the robot must stop at a finish line, explain how the system determines that the finish condition has been reached. A vague instruction like ‘move until finished’ is incomplete if no sensor or rule identifies the finish. Students should learn to make conditions explicit. This is computational thinking applied to a physical system: a program must interact with a real environment, not only produce a result on a screen.

Sequence, selection and repetition

Sequence is the order of instructions. Selection is choosing a path based on a condition. Repetition is performing instructions more than once. A mobile robot may use all three: first start the motors, then read the sensor, then choose whether to turn, and repeat the cycle while the task remains active. A mistake in any part may cause unexpected movement. Teach the student to trace the algorithm in a small table before running it.

For example, a robot checks a distance reading on each cycle. If the reading is above the threshold, it moves forward; if not, it turns. Ask the child to record the sequence for three hypothetical readings. This makes the control logic visible. If a student cannot explain the path for a single reading, do not add multiple sensors and more complex behaviour yet. Increase the difficulty only when the earlier logic can be applied independently.

Thresholds and calibration

Many sensor-based tasks depend on a threshold. A threshold is a chosen value used to separate one condition from another. If a system is programmed to stop when an object is closer than 15 centimetres, the reading of 12 centimetres should trigger the stop condition, while 25 centimetres should not. The student must understand whether the condition uses greater than, less than or an inclusive comparison. A single incorrect sign can reverse the intended behaviour.

Calibration helps a system produce more consistent results in its operating environment. A line sensor may need settings suited to the actual surface. A distance sensor may behave differently depending on the object and surroundings. Students should use the school’s method and record the calibration conditions rather than adjust values randomly. Ask what was measured, how the value was chosen and how the child knows the robot responds reliably. These questions turn trial-and-error into an experiment.

Programming: understand the logic rather than copying a block sequence

A beginner may use a visual block environment to control a robot. The blocks might represent motor commands, sensor readings, conditions, loops or timing. A child can drag blocks until something moves, but that does not prove they understand the program. Ask them to explain the purpose of each main block and predict what happens if one condition changes. The code should make sense before the robot is run.

If text-based programming is used, syntax matters as well as logic. A misspelled command, incorrect variable or missing bracket can stop the program. The school may use its own platform and coding language; parents should not introduce another tool unless the teacher approves. The best practice is a small modification to a known working example. Change one parameter, predict the result and test. This gives the student a direct link between code and behaviour.

Debugging a robot is more than fixing code

A mobile robot can fail for several reasons: an error in the program, incorrect motor connection, low battery, loose cable, sensor alignment, an unsuitable surface or a mechanical obstruction. Students should check the whole system in an orderly way. Start with a safe visual inspection and the task instructions. Confirm power and connections using the teacher’s approved method. Then run a simple sensor test or motor test if permitted. Change one factor at a time.

A useful debugging record has four columns: expected behaviour, observed behaviour, possible cause and next test. For example, the robot should stop before an obstacle but continues forward. The student checks whether the sensor reading changes as the object approaches. If the reading remains constant, the issue may be sensor positioning or connection, not the turning algorithm. This prevents random code changes that conceal the underlying fault. Students should report faults they cannot safely inspect.

Testing: use a controlled method

A test should answer a question. If the robot is supposed to follow a marked line, use the school-approved track and record where it leaves the line. If it should stop before an obstacle, place the test object at defined safe distances as permitted by the teacher. Use the same starting position and relevant conditions when comparing versions. A single successful run is not enough to establish consistent performance.

Record the number of trials and the results accurately. If the robot succeeds in four out of five tests, report that rather than writing ‘works perfectly’. Ask what differed in the unsuccessful trial. Was the line surface different? Did the battery level change? Was the robot placed at a different angle? A student should recognise that controlled testing helps identify patterns. The school may specify its own test protocol and safety boundaries; follow those rather than designing risky tests at home.

Variables and fair comparisons

When a student compares two versions of a robot, they should know which factor is being changed and which conditions are kept consistent. Suppose Version A uses a threshold of 12 and Version B uses 15, while the same track, robot, starting position and obstacle are used. The comparison is more meaningful if those other conditions remain similar. If the child changes the code, batteries and surface all at once, it becomes difficult to know which change caused the new behaviour.

A simple table can list the factor changed, factors held constant, observation and conclusion. The conclusion should be limited to the tests carried out. If Version B completed the same track more reliably in the trials, say that. Do not claim it will work in every environment. Students should learn that engineering decisions are based on evidence and that test limitations matter. This also connects robotics to the experimental reasoning developed in Science.

Safety: batteries, tools and moving parts

Robotics may involve batteries, wires, small components, wheels and moving mechanisms. Follow the school’s equipment and workshop instructions. Do not short-circuit batteries, open battery packs, use damaged cells, connect unknown power supplies or leave charging equipment unattended. Keep fingers, hair, clothing and loose objects away from moving parts. Do not dismantle equipment or use soldering, cutting tools or powered tools without explicit instruction and supervision.

A parent should not recreate a school robotics workshop at home using unfamiliar kits or exposed wiring. If the student reports a damaged cable, hot battery, unusual smell or a component that behaves unexpectedly, stop using the equipment and alert the responsible teacher or adult. Safety rules are not an optional part of the project. A robot that completes a route but creates an unsafe condition has not met a responsible design requirement.

Worked example: a simple obstacle-stop robot

Imagine a school task asks a small robot to move forward and stop before an object. The student identifies the input as the distance reading, the processing as a comparison with a chosen threshold, and the output as a motor stop command. The algorithm is written in steps before being coded. The robot is then tested with an approved object at a safe range under teacher supervision.

Suppose the robot stops too late. The student first records the actual distance, checks sensor position and compares readings with the programmed threshold. They do not immediately rewrite the entire program. After identifying the likely cause, they make one approved adjustment and run another test. The final reflection explains what changed and whether the result improved. This is a simple example of a complete engineering learning cycle.

Worked example: line-following behaviour

A school robot follows a dark line on a light surface using one or more sensors. The student observes how the sensor readings change when the robot is over the line or away from it. The program then uses a condition to adjust motor behaviour. If the robot drifts off one side, the learner notes the point and checks whether the sensor position, threshold or motor response explains the behaviour.

Do not assume all robots use the same sensor arrangement or steering rule. Some kits use different hardware and control methods. Follow the exact system provided by the school. The useful learning sequence is to observe, predict, run a controlled test, compare the outcome and make one justified change. A student who can explain why a robot corrected its direction has learned more than one who only knows which buttons to press.

The Fencing Method for robotics learning

Robotics combines hardware, software and physical conditions. When a learner struggles, remove some complexity. Start with a single motor command and observe movement. Add a second motor. Then read one sensor value without controlling movement. Next introduce a simple decision condition. Only after each part works should the student combine them into a moving robot. This makes it easier to identify which component is not understood.

The same principle applies to project testing. First test the sensor at rest. Then test one movement. Then combine them in a short route. Add a second condition only when the first is reliable. If the system fails, return to the last known working version. Keep copies according to school rules so that the student can compare changes. Complexity should increase because the learner is ready, not because a demonstration video makes a complicated robot look impressive.

Documentation: show the design and testing process

A good robotics record includes the task, system diagram, algorithm, test plan, observations, changes and reflection as required by the school. Label actual components and state what they do. If photographs or screenshots are allowed, ensure they show the student’s own work and do not reveal private information. Record the software version or kit where the teacher requests it. A neat final picture without test evidence may not explain how the robot was developed.

Use a short entry after each session: what was attempted, what happened, what was learned and what to test next. Students sometimes leave documentation until the final day and then cannot remember why a threshold was changed. A brief honest note written at the time is better. Do not manufacture trial results or claim the robot passed a test that was never performed. Accurate records are part of engineering responsibility.

Working in a robotics team

A team may divide programming, mechanical assembly, testing and documentation, but every learner should understand the overall design. A child assigned to document results should still know how the robot works. A child who writes code should listen to the observations made during testing. Team roles are a way to share responsibility, not a reason for one student to complete the entire task.

Ask the school how individual contributions are recorded. Use a task list that identifies the person responsible and the deadline. If a team member cannot complete a part, raise it early with the teacher rather than hiding the gap. Do not share passwords, school accounts or private contact details in public project files. Parents may help the child plan a respectful conversation about workload, but should not take over the project or communicate as though the student did the work.

What if the child is interested but has never used a robot?

Interest is a good starting point. A student can begin by identifying inputs, outputs and simple instruction sequences using diagrams or teacher-approved simulations. There is no need to purchase an expensive kit or compete with learners who have attended robotics classes for years. Prior exposure differs. The school should explain the assumed starting knowledge and provide suitable introduction.

Parents can ask the child to describe a familiar automatic system, such as an automatic door or a light that responds to movement. What might the system detect? What action follows? What could cause a false response? The answer need not claim detailed knowledge of the real commercial system. It is a way to practise structured thinking. Move to actual robot hardware only in the approved learning environment and under appropriate guidance.

Four weeks left: organise project and practical preparation

If a school robotics assessment is four weeks away, use the first week to understand the rubric and identify the main system components. Use the second to stabilise the basic algorithm and hardware connections in school. The third is for controlled testing, debugging and documentation. The final week checks reliability, safety, explanation and submission. This outline must be adapted to the teacher’s actual milestones and workshop access.

If only seven days remain, do not introduce an entirely new robot design. Check the existing program, power and approved connections, test the core function under the specified conditions and prepare a short explanation of the input-process-output sequence. Complete honest test records. If a component is faulty, inform the teacher. A safe, clearly explained solution is better than an impressive but unstable system that the student cannot describe.

A sustainable weekly practice routine

A student may benefit from one or two short focused sessions in addition to school lessons, but the exact time depends on access to the equipment and the rest of the timetable. A 20-minute paper-based session could review the algorithm, draw the system and predict what a sensor condition does. Actual hardware practice should occur only where permitted. A longer weekend session can be used if the school provides an approved supervised opportunity.

End each session with a specific statement: ‘I can explain how the sensor reading controls the motor’, or ‘I still need help understanding why the threshold causes the turn’. This is more useful than saying ‘I played with the robot for an hour’. Protect physical activity, rest and other subjects. Robotics should develop curiosity and careful problem-solving, not become a late-night screen and hardware marathon.

Robotics anxiety: when every failure looks like a broken project

A robot that does not move can be frustrating. The child may believe that the project has failed and they are not capable. Teach them to separate an observed fault from a personal judgement. Ask what the robot should do, what it actually did and which part of the system might explain the difference. Return to a small test that is known to work. Rebuilding confidence begins with evidence.

If a student becomes distressed, pause the task and do not keep changing components under pressure. Seek teacher assistance for equipment or code they cannot safely inspect. If anxiety persists and affects sleep, attendance or everyday functioning, involve the school’s support team or a qualified healthcare professional. Robotics is supposed to develop confidence through experimentation. A young person should not feel that a malfunctioning model determines their worth or future.

What K130 means for a future subject decision

SEAB identifies Mobile Robotics K130 as an MOE–ITE Applied Subject for 2027 school candidates. The published list says the subject is only applicable to candidates from schools approved to offer it and that 2027 is the final year of examinations for MOE–ITE Applied Subjects. Families should therefore avoid assuming that K130 will be available in every school or remain an examination option for future cohorts. The school’s current applied-subject coordinator must confirm eligibility and relevant arrangements.

A Secondary 2 student who enjoys robotics may have other routes through computing, D&T, applied learning, STEM programmes, CCA, school projects or later post-secondary technical courses. These routes have different requirements and are not all national SEC subjects. Ask the school what opportunities exist for this cohort and what skills the student should develop. A student’s curiosity and practical problem-solving matter even when a particular qualification has limited availability.

Full SBB progression is not decided by a robotics activity

The common academic requirement at the end of Secondary 2 and Secondary 3 is applied using the student’s examinable subjects and school guidance. Published school information describes the requirement as passing English Language and two other examinable subjects, or passing at least half the examinable subjects offered. CCE, PE and lower-secondary Music are excluded in the cited progression explanation. A school robotics CCA or project should not automatically be treated as an examinable subject pass.

This distinction helps parents protect the student from false promises. A successful robot project may show interest, persistence and technical reasoning, but does not automatically secure a particular G1 subject placement or national applied-subject candidature. Obtain the student’s full academic report and ask the school which options are available. A strong education plan recognises applied strengths while maintaining the academic foundations required for the student’s next step.

What support should parents choose?

Begin with the teacher who knows the kit, safety arrangements and curriculum. Ask which concept is unclear and what independent evidence would demonstrate progress. A general coding tutor may not understand the hardware or assessment rubric. A robotics specialist should be able to explain the actual school platform, keep students safe and teach them to test rather than simply assemble a pre-written model.

Paid support is not compulsory. If the child can explain the algorithm, demonstrate the basic function and correct simple errors, teacher-led practice may be sufficient. Additional help may be useful when the student repeatedly copies code without understanding or cannot connect sensor input to motor output. Avoid providers promising national examination grades for a subject the child may not be enrolled in. The aim is authentic independent capability, not a commercially impressive photograph.

Frequently asked questions for Secondary 2 Mobile Robotics parents

Does every Secondary 2 G1 student take Mobile Robotics?

No. It is not a universal Secondary 2 subject. The national MOE–ITE Applied Subject is restricted to candidates from approved schools.

Is K130 a standard Secondary 2 EOY code?

No. K130 is the 2027 national SEC code for MOE–ITE Mobile Robotics. A school module or robotics CCA is a different programme.

Is the Mobile Robotics examination continuing after 2027?

SEAB’s published 2027 school-candidate list states that 2027 will be the last year of examinations for the MOE–ITE Applied Subjects. Families should seek current official advice for any later programme.

Should we buy a robotics kit at home?

Not automatically. Ask the school what hardware is used and whether home practice is needed. Diagrams, algorithms and approved simulations may be sufficient for some learning outcomes.

What if the robot repeatedly fails?

Record expected and actual behaviour, inspect only what the student is authorised to inspect, test one factor at a time and ask the teacher when a hardware issue is suspected.

Can the student use AI to write the robot code?

Only if school rules allow it. The student must understand and test the code and acknowledge assistance where required. Never use unapproved tools or private school information.

Does a robotics CCA result count as an examinable pass?

Do not assume so. A CCA, enrichment project and national applied subject have different status. The school confirms the academic progression calculation.

Does robotics guarantee an engineering pathway?

No. It can help a student explore interest and develop useful skills, but later study and career routes depend on actual qualifications, choices and admission requirements.

Related eduKate and official information

For systematic learning and digital focus, see the Full SBB focus guide, the free resources guide and the test anxiety guide. The eduKate first-principles teaching reference explains why a student should understand each step, practise with guidance and then demonstrate independent transfer.

For official qualification details, read SEAB’s 2027 G1 subject list and confirm the MOE–ITE Applied Subject restriction and final examination year. Use the student’s own school for approved programme availability, kit and software rules, practical assessment and safety arrangements. National subject information cannot certify that a particular school offers Mobile Robotics.

What good preparation should leave the child able to do

A prepared learner should be able to describe the robot’s purpose, identify its sensors and outputs, explain the main algorithm, predict a simple behaviour, test it safely, record an observation and suggest a justified improvement. They should also know when to stop and ask for help rather than handle damaged wiring or unfamiliar equipment. These are meaningful technical habits whether the child is participating in a CCA, a school module or an approved applied subject.

Use the cycle: understand the brief, identify the system, plan the algorithm, test one component, combine parts, observe, debug and explain. If the learner is confused, reduce the problem to the last known working stage. When the method is secure, introduce one new condition or test. This prepares a Secondary 2 student for responsible applied learning without implying that every student is sitting the same G1 EOY paper or is eligible for K130.