The honest answer to how to assess robotics projects is this: grade the thinking that produced the robot, not the thirty seconds where it drives across a table. A working demo tells you a team eventually got there. It does not tell you who understood the code, who copied a friend, or whether a lucky wire tuck saved a design that was actually broken. Good assessment in a robotics class looks at process evidence gathered along the way, and it treats debugging as a skill worth marks in its own right.

This matters most in June, when Term 2 reports are due and you are trying to turn a term of noisy, hands-on work into a defensible number. If your only artefact is a final run, you have very little to write about. If you have journals, logs and short explain-backs, the mark almost writes itself.

Why "it moved" is a weak grade

A final demonstration is a single sample of a noisy system. Batteries sag, floors have grip that the test bench did not, and a line-follower tuned in morning light behaves differently under afternoon sun through the window. Two teams can arrive at the same visible result by very different routes: one reasoned their way there, the other brute-forced it by changing numbers until something worked. Marking only the outcome rewards both equally, which quietly teaches your strongest students that understanding is optional.

It also punishes ambition. A team that attempts a harder mechanism and gets 80% of the way there can look worse on demo day than a team that played it safe. If your rubric only sees the finish line, students learn to pick easy problems. Assessing the process lets you reward the harder attempt honestly.

Assess the process, not just the product

Shift most of the weight onto evidence students generate while they work. Three artefacts do almost all the heavy lifting, and none of them need special software.

• Design journals. A short, dated entry each lesson: what we tried, what we expected, what actually happened, what we will change next. Half a page is plenty. The value is the gap between expected and actual, because that gap is where learning lives.
• Iteration logs. A running list of versions with a one-line reason for each change. "v3: slowed left motor, robot was veering right." This is the single clearest window into whether a student is reasoning or guessing. On our block coding canvas the save history already shows this progression, so the log can be as simple as annotating which saves mattered and why.
• Peer explain-backs. Before a project counts as done, one team member explains a chosen section of the code or build to another group in plain language. You listen for two minutes. A student who wrote the logic can narrate it; a student who copied it stalls at the first "why this and not that".

The point of all three is to make invisible thinking visible so you have something to mark other than the last run.

A rubric that rewards debugging

Debugging is the actual work of robotics, so it should carry real weight rather than being treated as failure to be hidden. A rubric that names it changes how students behave: they start writing down what broke instead of quietly reverting to a backup and pretending it never happened.

A simple four-strand rubric works well for a standard project on the sheenbot board or any similar kit. Split the marks so no single strand can carry a weak project on its own.

• Understanding (25%) — can the student explain what each part of their solution does and why.
• Process and iteration (30%) — quality of the journal and log; evidence of testing a change against a prediction rather than random tweaking.
• Debugging (25%) — how a fault was isolated and fixed; a clearly documented bug that was found and solved should score higher than a project with no recorded problems at all.
• Outcome (20%) — does the final build meet the brief. It still counts. It just does not dominate.

Note that the outcome is the smallest strand. That is deliberate. When students see that a well-hunted bug earns more than a suspiciously clean project with no history, they stop hiding their struggles and start showing their working.

Group work and fairness

The oldest complaint in any practical subject is the passenger: one student drives the laptop while the others watch. Process evidence is your best defence, because it is individual by design. Each member keeps their own short journal, and the explain-back is done by a named student on a section you choose, not one they rehearsed. Rotate a visible role each lesson so the driver, the builder and the tester are different people week to week, and record that rotation.

Keep a small portion of the mark individual and the rest shared. A common split is roughly 70% team, 30% individual, where the individual portion comes almost entirely from that student's own journal and their explain-back. It is enough to make coasting visible without turning a collaborative project into four solo ones. Competition formats already lean this way: teams heading toward FTC are judged on an engineering portfolio that documents the whole season, not just the robot on match day, which is exactly the habit you are building in class.

Making it sustainable

None of this survives if it doubles your marking load. Keep the instruments light. Journals are half a page and marked with a tick-and-flick against three questions, not a paragraph of feedback each. Explain-backs happen live during the lesson, so they cost you listening time, not evening time. Iteration logs you skim, not read line by line. Build the checkpoints into the lesson sequence from the start rather than bolting assessment on at the end, the way our academy curriculum spaces short reflective stops through a project instead of one big judgement at the finish. Assessment that lives inside the work is far more sustainable than a separate marking event.

Takeaway

"The robot moved" is a starting point, not a grade. Shift the weight of your assessment onto process evidence: dated design journals, honest iteration logs, and short peer explain-backs. Build a rubric that pays students for understanding and for debugging, and keep the final outcome as the smallest strand rather than the whole story. Do that and your reports get easier to write, your quiet passengers get harder to hide, and your students learn the lesson that actually transfers beyond the classroom: in real engineering, the thinking is the product.