How to Grade Individual Learners When Four Kids Share One Robot Kit
Group robotics projects frequently hide coasting learners. You can assess individual competence accurately by separating the shared build from three individual checkpoints: role-specific artifacts, paper-based code tracing, and 60-second oral vivas.
When four learners share a single robot kit, standard group grading guarantees an inaccurate mark. In almost every team of four, one dominant learner writes the block code, one builds the chassis, and two passively watch the screen or wander across the computer lab. Giving all four learners the same 85% for a line-following challenge rewards coasting and conceals severe learning gaps before high-stakes terms begin.
The solution is not to buy four times as much hardware. The solution is to decouple the physical group outcome from individual assessment. The team shares the chassis and sensor bus, but every learner is graded on three distinct individual touchpoints: assigned role documentation, an individual trace assessment, and a 60-second live code viva.
The Four-Role Rotation Framework
Sharing hardware fails when roles are informal. If you tell learners to "work together to program an ultrasonic obstacle avoider", the fastest typist takes the keyboard. You must enforce explicit, non-negotiable roles that rotate every project cycle or every week.
For a four-learner team, establish four functional roles, each tied to an individual assessment artifact that the teacher grades separately from the running robot:
| Role | Responsibility During Build | Individual Assessed Deliverable |
|---|---|---|
| Lead Programmer | Inputs code, sets variable logic, handles syntax. | Annotated code export with written explanation of logic branches. |
| Hardware Engineer | Wires sensors, mounts motors, monitors battery draw. | Pinout wiring diagram with pin/port assignments and sensor thresholds. |
| QA & Test Engineer | Designs test protocols, measures distances/tolerances. | Test log with input values, observed vs expected robot behaviour, and bug reports. |
| Project Systems Lead | Manages time, coordinates integration, tracks constraints. | State-machine diagram or flowchart showing complete system sequence. |
If the robot works, the team gets a baseline group score (for example, 20% to 30% of the overall task mark). The remaining 70% to 80% comes entirely from the individual deliverable and direct verification of individual competence.
The 60-Second Code Viva
The single most reliable tool for uncovering whether a learner understands the program running on the robot is the live oral walkthrough. In a 45-minute period with 10 groups (40 learners), you cannot hold extended interviews. You can, however, execute 60-second vivas while teams are testing on the floor.
Call one learner over to the laptop. Point to a random line or block of code and ask one of three diagnostic questions:
- "What will the robot physically do if I change this comparison operator from > to <?"
- "Why is this sensor read inside the loop rather than in the setup block?"
- "Point to the exact block of code executing when the left wheel reverses."
A learner who built the logic answers immediately. A passenger who let their teammate do the work freezes or gives vague answers like "it makes the motor go". Record a mark on a simple three-point scale (0 = no understanding, 1 = partial understanding, 2 = clear mastery). In under ten minutes, you can assess ten learners individually without halting class progress.
The Paper-Based Code Trace
When computing labs lack reliable power, or when load-shedding interrupts an active session, paper-based tracing tests are the most robust equalizer. This is also aligned with how formal computing assessments under the CAPS Coding and Robotics curriculum evaluate algorithmic logic.
Provide learners with an excerpt of the project’s code printed on paper (or projected on a screen), but introduce a deliberate bug: a misplaced delay, an inverted conditional check, or an incorrect variable scope. Give learners five minutes independently to write down:
- What line contains the logical error.
- What the robot will physically do because of that error.
- The corrected pseudocode or block parameter.
This strips away the advantage of having a fast peer sitting next to them. If a learner cannot trace execution flow on paper, they did not understand the code running on their team's robot.
Structuring the Grade Breakdown
To keep grading manageable across large cohorts while maintaining individual accountability, structure your project rubrics according to this weighting:
Group Component (30%): Did the integrated physical build meet the design specifications and perform the required autonomous task?
Individual Role Deliverable (35%): Did this specific learner produce a complete, accurate role artifact (wiring diagram, state flowchart, or QA log)?
Individual Competence Check (35%): Did the learner demonstrate understanding during their viva or paper-based code trace?
Using this distribution, a team that builds an exceptional maze-solving rover will see its active programmer score 92% and its disengaged passenger score 48%. This outcome is fair, transparent, and immediately informative for parent feedback and term reporting.
For schools managing multi-class implementations and standardized tracking across grades, our team at Sheen School Services provides tailored assessment rubrics, role templates, and educator workshops designed specifically for South African timetable and classroom constraints.
