Arduino Project Rubric: Grading Sheet, Hand-in Form, Portfolio

If you grade an Arduino project only by asking “does it work?”, you can end up giving the same mark to a student who copied a friend's code and to one who rebuilt the circuit three times and found the bug on their own. A fairer Arduino project rubric looks at five dimensions: the circuit (is it built correctly and neatly), the code (can the student change something on purpose), understanding (can they explain a line you pick), the debugging process (what did they do when it failed) and documentation and presentation (can they show what they did). Circuit, code and documentation measure the product; understanding and debugging measure the process. When more than half of the grade comes from the process, students stop hiding mistakes and start explaining them.

This post is a set of templates you can take to class tomorrow: a 6-criterion, 4-level main rubric, weights, a one-page project hand-in form, a 40-minute hand-in lesson, a 5-minute desk checklist, self and peer assessment forms, a term portfolio and a step-by-step grade calculation for one student. The examples assume a hypothetical class of 24 working in groups of three. If you want a shorter 3-level table for quick observation in weekly lessons, use the rubric in the 8-week robotics coding lesson plan; the set below is meant for the grade you give at the end of a project.

Why “does it work?” is not enough: 5 dimensions

In Arduino projects the product and the learning do not always sit in the same place. A traffic light whose LEDs light up in order may mean the student uploaded the code without ever reading it. A night light that never turns on may be the attempt in which the student measured the sensor value in the Serial Monitor and found a badly chosen threshold, which is exactly what the lesson was about. That is why it helps to split the rubric into two families. On the product side you look at the circuit, the code and the documents handed in; that evidence sits on the desk, on paper and in a photo. On the process side you look at how the student talks and the path they follow while hunting a bug; you only see that by asking and watching. The table below sums up what to look at in each dimension and where the evidence comes from.

The main rubric: 6 criteria, 4 levels and weights

We added a sixth criterion to the five dimensions: work habits, safety and teamwork. In an Arduino lesson taught in groups, swapping wires while the USB cable is plugged in or dropping your role and stepping aside is part of learning too. Every level is written as an observable behavior; instead of vague phrases like “understands well” you get things you can see at the desk, such as “explains the chosen line correctly and says what happens if it changes”. Seeing the behavior in a cell once is enough to place a student at that level. If you are torn between two levels, write down the lower one with a short note; it is the first thing you check in the next project.

The weights are deliberate: 45% of the grade comes from the product (circuit, code, documentation) and 55% from the process (understanding, debugging, work habits). Understanding carries the most weight because in a lesson where code is easy to copy, the student's own explanation is the most reliable sign of what they really learned. In the first projects you can raise circuit building to 25% and lower code to 10%; in the early weeks students mostly upload ready-made code anyway. In the second half of the term, once they start combining two projects or adding their own behaviors, it makes more sense to raise code to 20% and lower the circuit to 15%. Keep the total at 100 and share the weights with students before the project starts; a student who knows what earns points fills in the hand-in form more carefully as well.

Project hand-in form template

The hand-in form is one page, and the group fills it in before showing the project. It is not meant to be a fancy report but a single place that collects the rubric's evidence: the parts list and connection table support the circuit criterion, the changed line supports code, the bug and its fix support debugging, and the photo and video support documentation. You fill in the last row, “What does this line do?”, yourself. The example below is the form of a hypothetical group that built the free BlueGrays project Night Light with Ldr. The parts list comes from the project's Required Components section and the connections from the Circuit Diagram. Clear the third column when you copy the template.

The power of the “What does this line do?” question is that it shows what a student really understands, even in copied code. Pick a different line for each group member and write the answer in the last row of the form. A good line is one that changes how the program behaves: a pinMode(), an analogRead() or digitalRead(), an if condition, a delay(). Do not pick a curly brace or an empty line. Ask in two steps: first “what does this line do?”, then “what happens if you change the 13 in this line to 12?” A student who answers the second question correctly lands on 3 for understanding; one who can walk you through the whole program lands on 4. When you pick lines in ready-made projects, the Step by step explanations in the project's Understand the code tab guide you to the lines at the heart of the program quickly. We covered how to read that tab through a student's eyes in Understand the code and Try it yourself.

Hand-in lesson: assessing 8 groups in 40 minutes

5-minute desk checklist

Print this list on A4 and use one copy per group. The order is deliberate: power and circuit first, then code, oral questions last. If the project does not work, do not stop halfway; the remaining items collect evidence for the debugging criterion. Allow at most 5 minutes per group; after a few hand-ins most checks take 4 minutes.

• Power: The board is powered over USB and its power LED is on.
• Shared GND: The breadboard's minus rail is connected to the Arduino's GND pin; the sensor and the LED are on the same rail.
• Parts: The LED faces the right way (long leg on the plus side), every LED has a resistor in front of it, the resistor values match the form.
• Compared with the diagram: The pins used are exactly the same as in the connection table on the hand-in form.
• Code: The code on the board contains the change on the form; if you are not sure, ask the group to upload it once more.
• Behavior: The project does what it should; if not, the group can say why or which step they are trying right now.
• Show the change live: The group sets the changed value back to the original and shows the difference.
• What does this line do? Each member was asked about a different line and the answer is on the form.
• Bug log: There is at least one entry for this project: symptom, what was tried, the fix.
• Evidence: There is a clear photo of the circuit taken from above and a 10–20 second video of it working.

Self-assessment form

The self-assessment form helps students put a name to their own learning and gives you a second view to compare with your rubric. Every student fills it in individually; it is not a group form. The last column matters most: ask a student who ticks “Yes” to write down a piece of evidence. Self-assessment does not count toward the grade, but if the level you gave and the student's tick are two steps apart, that is a good cue for a one-minute talk with that student. Sometimes students sell themselves short, and sometimes they remember a moment you missed.

Peer assessment form

The peer form is filled in while groups try each other's projects. Set the rule from the start: no points, only observations and suggestions. Students grading a classmate is neither fair nor good for the mood in the room, while a “two likes, one suggestion” structure teaches how to give useful feedback. If you like, you can use the quality of the suggestion a student writes as evidence for the teamwork criterion. Hand the completed form back to the group that owns the project; that is the copy that goes into the portfolio.

Portfolio: what to collect over the term

A portfolio tells the story of the term, not of a single project. Putting a student's hand-in form from their first LED project next to the form from their last project shows growth better than any single number. Paper or digital does not matter; what matters is adding the same items with the same naming in every project. For a digital portfolio, the cloud folder or learning platform your school already uses is enough: one folder per student, one subfolder per project, with file names starting with the project number, the project name and the version. For a paper portfolio, a ring binder with a divider per project does the job.

The most valuable part of the portfolio is the bug log, because that is where the evidence for the debugging criterion lives. Each row answers six questions: date and project, symptom (what happened?), first guess, what was tried (in order), the real cause and what I will do next time. A sample row: “12 November, Night Light with Ldr; the LED never turns on; guess: LED reversed; we turned the LED around, nothing changed, we printed the value to the Serial Monitor; real cause: a threshold of 50 was too low for the classroom light; next time I will measure the sensor value first.” A log that collects 10–15 rows over the term shows which mistakes a student no longer makes. Have them log compile errors too; they can look up the most common ones in Arduino compile errors and learn to read sensor values in how to use the Serial Monitor.

Data from the app: what BlueGrays gives you and what it doesn't

If your students use BlueGrays on their own phones, some parts of the app provide small but useful evidence for assessment. What they all have in common is that the student shows the information to you on their own screen; the app does not send it to the teacher separately. So use them not as a grade on their own but as evidence that starts a conversation and completes the portfolio.

• I made it: When students finish a project they tap this tile on the project page, and the project lands in Workshop > Completed Projects. During a portfolio check, ask the student to open this list; it becomes a quick index of the projects they built over the term. Marking it takes one tap, so it is a claim rather than proof: for every project on the list, look for a hand-in form or a photo in the portfolio.
• Oral check with Try it yourself: The Try it yourself task at the end of a project's Understand the code tab is one step beyond “What does this line do?”. Read the task aloud and ask the student to say, without looking at the phone, which line they would change and how; then let them make the change and upload it. Agree from the start that they say openly whether they used the Hint or Show solution: solving it with the hint can be a 3 for understanding, solving it without the hint and explaining why can be a 4.
• If you get stuck and Troubleshooting: A group that works through the If you get stuck section in Understand the code, or the project's Troubleshooting list where there is one, is showing a method in debugging. Ask which item helped them find the bug and have them write it in the bug log.
• Daily questions and My level: The question set that changes every day, the XP and the levels from A1 First Light to C2 Workshop Master are a good way to keep students busy with electronics between lessons, but do not turn them into grades. The questions are answered at home and alone, the level never drops and the result depends on how much time a student can spare. Use them for motivation: students who want to can share their new level with the class at the end of the week, and nobody is required to.

Grade calculation example: one student's score

Say Sam is the reader in the group that built the Night Light with Ldr project. Your observations in the hand-in lesson are these: built the circuit from the diagram without mistakes (circuit 3); changed the threshold but did not add a new behavior (code 2); explained the if line, said that with a threshold of 600 instead of 300 the LED would turn on in less darkness, and walked through the whole program (understanding 4); suggested printing the value to the Serial Monitor when the LED did not light and wrote it in the log (debugging 3); the hand-in form had a photo but the connection table was missing (documentation 2); did the role and helped the group next door (work habits 4). There are two ways to calculate the score. With the linear method, each criterion scores its level divided by 4 times the weight. With the soft conversion, levels count as 1 = 50%, 2 = 70%, 3 = 85%, 4 = 100%, so a student who got started but struggled does not get close to zero on a criterion.

Sam's grade is 77.5 out of 100 with the linear method, 78 when rounded; with the soft conversion it is 86.5, so 87. Whichever method you choose, use the same one all term and explain it to students before the first project; you can then map the percentage onto your school's grading scale. The table tells you more than a number, it tells you what to do next: Sam's two lowest criteria are code and documentation. In the next project you can set the goals of adding a new behavior (for example a short buzzer beep in addition to the LED when it gets dark) and preparing the connection table without help. If you put the weights and the conversion into a spreadsheet, the grades of all 24 students appear as soon as you enter the levels.

Fair assessment: group work, circuits that don't work, copied code

• Individual contribution in a group: Product criteria (circuit, code, documentation) can be given to the group as a whole, process criteria (understanding, debugging, work habits) are always individual. Asking every member about a different line with “What does this line do?” builds in that split. Rotate the roles (builder, checker, reader) in every project, so that by the end of the term every student has taken on each role at least once.
• A circuit that doesn't work: If the project does not work at hand-in, give at most 2 for the circuit, but do not lower the process criteria. A student who searched for the bug systematically, logged it and can explain where they got stuck can get 3 or 4 for debugging. If you like, allow one correction until the next lesson and reassess the circuit score.
• Copied or ready-made code: Starting from a ready-made project is not copying; lessons work with ready-made code anyway. The real question is what the student did with the code. Since the code criterion looks at the change and the understanding criterion looks at the explanation, code taken from another group but not understood stays low on those two rows by itself. The “Which project did I start from?” row on the form makes naming the source, instead of hiding it, a habit.
• Code written with a chatbot: In projects done at home, the code may have been written with an AI tool. Instead of banning it, increase the oral check at hand-in: points go to the student who can explain and change the code, not to whoever wrote it.
• Broken parts and absences: If a group's sensor is broken or a student is absent on hand-in day, do not fill in the rubric that day; complete it with a short desk check in the next lesson. A problem caused by the materials should not show up in a student's grade.
• Everyone knows the same table: Read the rubric with your students before the first project and show one example of each level. Students who know the level descriptions ask what they need to do for the next level instead of disputing their grade.

You do not need to wait for a big project to try the rubric for the first time: start with a one-lesson project such as Night Light with Ldr or Traffic Light, use the hand-in form and the checklist once, then adjust the weights to your class. If you are placing the assessment at the end of a longer program, the 3-minute presentation template in the 5-day Arduino workshop post works well together with these forms. If your students open the projects in BlueGrays, the parts list, the circuit diagram and the Understand the code steps that feed the “What does this line do?” question are already there; you can start with 60 free projects, 20 per platform, and when you move on to Premium projects you can hand out codes from one-time, non-renewing 5- or 10-code packages under Profile > Educator Packages instead of having each student take out a subscription.