Start with an assessable idea
“Use the robots” describes an activity, not a learning objective. A more useful target is “explain how a repeated sequence can be replaced by a loop” or “compare a predicted route with an observed route.” The equipment then becomes a way to investigate an idea rather than the focus of the entire session.
Choose one main concept for the first lesson. Combining unfamiliar construction, new software, wireless pairing and a complex challenge makes it hard to identify why learners struggle. Prebuild the chassis if the objective is programming. Provide working code if the objective is comparing wheel sizes or structural stability.
Prepare the room and the equipment
Charge equipment according to its instructions and label each robot with its matching storage space. Check the actual classroom devices, network rules and account requirements before the lesson. A successful connection on a teacher’s personal laptop does not establish that managed tablets will work the same way.
Create a defined test area away from doors and walkways. Keep charging cables out of circulation routes and establish a stop signal everyone understands. Check access from seated positions, table heights and noise levels. Store spare parts where an adult can distribute them without interrupting every group’s work.
Use a simple lesson structure
The following is an illustrative 50-minute plan, not a claim about an ideal lesson length. Adjust it for transitions, learner needs and equipment complexity. The challenge is to program a route containing a repeated movement pattern and then express that repetition more clearly.
- First 8 minutes: demonstrate one short sequence and ask learners to predict its result.
- Next 8 minutes: groups sketch a route and write their initial instructions away from the device.
- Next 18 minutes: groups run, observe and revise their programs, keeping a brief change log.
- Next 8 minutes: compare a repeated sequence with a loop-based version and explain the relationship.
- Final 8 minutes: save work, return equipment and complete an individual reflection.
Protect reflection time. If connection problems consume the practical phase, use a printed program and trace it together rather than rushing directly from setup to cleanup.
Share the thinking, not just the device
Small groups can assign a programmer, a tester and an observer, with roles rotating after each trial. The programmer enters the agreed plan; the tester prepares the start position; the observer records the outcome. Everyone should predict the result before the run. Do not let one confident learner become the permanent operator.
Roles should support access rather than restrict it. A learner who cannot easily manipulate small components can still direct a build or evaluate a program. Offer large command cards, written instructions, spoken explanation and diagram-based responses. Avoid using speed of assembly as a proxy for understanding.
Assess the explanation
A robot reaching its destination is incomplete evidence: a group may have copied code or succeeded by chance. Ask each learner to explain one instruction, identify a change and connect that change to an observation. A short annotated route or a before-and-after program can reveal more than a polished final demonstration.
Useful assessment dimensions include prediction, systematic testing and explanation. Look for whether the learner changes one relevant factor, records what happened and uses evidence to choose the next step. Keep collaboration separate from technical accuracy so a mechanically unreliable robot does not erase evidence of careful thinking.
Keep a fallback and a progression
Prepare an unplugged version of the same objective. Learners can act out commands, trace blocks on paper or diagnose a deliberately flawed sequence. This is not merely spare entertainment; it preserves the learning goal when a device fails. Never require families to create private accounts just to complete a classroom task without the school’s approval.
End by identifying the next conceptual step. Sequence can lead to loops, loops to conditions, and conditions to sensor-based control. Review which practical bottleneck mattered most before purchasing more equipment. The selection guide helps turn classroom requirements into a shortlist, while the block-coding guide supports the next programming challenge.