Project-Based Learning with Arduino: A 4-Week Sample Unit

Project-based learning with Arduino is a unit design in which students learn the content not after a lecture, but while trying to solve a real problem. The flow has five stages: you ask a driving question, teams research the problem and decide what to measure, they build a prototype with Arduino, they test and improve it around the school, and finally they present what they found to a real audience. The driving question of the sample unit in this post is: "How can we measure an energy, water, noise or classroom air problem at our school and warn people about it?" Over four weeks each team picks one of these problems, measures it with a sensor, builds a working device that gives a warning when a threshold is crossed, and uses the data it collected to make a recommendation to the school.

Below is everything you can take into class tomorrow: a week-by-week unit table, a lesson-by-lesson flow with exit questions, four problem scenarios with starter projects in BlueGrays, a materials list, a team contract and roles, the prototype loop and a test log template, checkpoint and final presentation criteria, common PBL pitfalls and a checklist. The examples all use the same assumption: let's say you have a class of 24, two lessons a week (2 × 40 minutes) and six teams of four. If you're looking for a plan that teaches skills in order, the 8-week robotics coding plan is a better fit, and for a short, intensive programme the 5-day Arduino workshop is. This unit works best after those, once students have already lit an LED and read a sensor.

What is project-based learning, and how is it different from a project assignment?

In the classic order, the topic is taught first and a project is handed out afterwards so students can show what they learned; the project is the dessert, not the meal. In project-based learning the order flips: the project is the lesson. Students learn analogRead(), thresholds or averaging at the moment they need them to solve the problem. Arduino fits this approach well because it turns the real world into numbers: an LDR measures the light in the corridor, a sound sensor the noise in the cafeteria, a DHT11 the temperature in the classroom. Prototypes are cheap and change in minutes; if a threshold is wrong, you change one number in the code and upload again. That squeezes the "try, measure, fix" loop at the heart of PBL into a single lesson. The table sums up the difference:

The driving question: one sentence that carries the unit

The driving question is the question that stays on the classroom wall for four weeks and that every lesson connects back to: "How did we get closer to this today?" In this unit the shared question is deliberately broad so that every team can pick its own piece: "How can we measure an energy, water, noise or classroom air problem at our school and warn people about it?" The job of the first week is to narrow this broad question down to the team's own sub-question. "Wasting energy at school" is not a sub-question; "How many minutes do the lights stay on in the empty class 7B during break, and who should we warn, and how?" is. The answer to a good sub-question starts with a number and ends with a device. Before you approve a team's sub-question, check it against these six criteria:

• Real: Someone at school actually has this problem and the team can say who: the teacher on duty, school staff, the cafeteria staff or the class representative.
• Measurable: A sensor you have turns the problem into a number: light, sound level, soil moisture, temperature or distance.
• Local and narrow: There is one place and one time slot; not "the school" but "second-floor corridor, lunch break".
• Open-ended: The answer isn't yes or no; the question asks "how", "when" or "how much".
• Fits in 4 weeks: The solution doesn't require touching mains wiring, joining the school network or waiting for budget approval.
• Ends with a warning: The device doesn't just measure and stay silent; at a threshold it alerts someone with an LED, a buzzer or a display.

A 4-week project-based learning unit

The plan is built on 8 lessons: two a week, 40 minutes each. The weeks follow the five PBL stages, but there's no thick wall between research and prototyping; in week 2 a team may still be narrowing down its problem, and in week 3 a new measurement may raise a new research question. What matters is that the output in the table exists at the end of each week. Your role changes week by week too: at first you're the one asking questions, in the middle you're the coach, and at the end you're the organiser who brings the audience into the room.

The table below breaks the same plan down lesson by lesson. The last 3 minutes of every lesson are for the exit question; the team writes its one-sentence answer at the bottom of the test log. These answers become the warm-up for the next lesson and the evidence of the process in the final presentation. Keep mini-lessons to 10 minutes; anything longer eats into the teams' working time and the unit quietly turns back into a classic lesson.

4 problem scenarios and their starter projects in BlueGrays

Don't expect teams to write code from scratch; in PBL the goal is to solve the problem, not to write a program from the first line. For each scenario BlueGrays has a ready starter project with a circuit diagram, parts list and code; the team builds it, understands it and adapts it to its own problem. The free projects in the table are open to everyone, the Premium ones require Premium. With six teams, let at most two teams pick the same scenario. If two teams on the same scenario measure different places, you also get a comparison in the presentations.

Be honest with students about two things from the start. First, the KY-038 is not a decibel meter: it turns the fluctuation the microphone picks up into a number between 0 and 1023. The team can't say "the cafeteria is at 85 dB", but it can say "at lunch the cafeteria gives much higher values than an empty classroom" and show the difference in numbers; comparative data is enough for PBL. You'll find how the sensor responds and how to adjust it in the KY-038 sound sensor post. Second, a DHT11 measures temperature and humidity, not stuffiness; in a closed classroom what really rises is carbon dioxide. The classroom air team can base its "open the windows" recommendation on temperature and humidity and say in the presentation that the next step is measuring CO2. For the energy and water teams' sensors, the LDR light sensor and soil moisture sensor posts cover calibration in detail.

Materials list: 6 teams + 1 spare kit

Team contract and roles

In a team of four, if not everyone has a job, the fastest student does the work and the others watch. The simplest fix is four roles and a weekly rotation: 4 weeks, 4 roles, everyone takes each role once. A role doesn't mean "I only do this"; it means "I answer for this". The code lead isn't the only one who writes code, but that week they're the one who explains what the code does to the class. The team writes the contract itself in the first lesson; you only make the items below mandatory and approve it once all four have signed.

• Our sub-question: .................................................. (one sentence, one place, one time)
• Our success criterion: When .................. goes above .................., our device will warn with ...................
• Roles (week 1): Project manager ........, circuit ........, code ........, data and documentation ........ We rotate the roles by one person every week.
• Decision rule: If we can't agree, we measure first; if there's no measurement, the project manager decides and writes the decision in the test log.
• Help rule: Before going to the teacher, we check the diagram, the project's Understand the code section and a teammate.
• Absence: A teammate who misses a lesson reads the test log in the next lesson and catches up in 2 minutes; someone else covers their job that week.
• Signatures: .............. .............. .............. ..............

The prototype loop: the minimum working version

PBL units most often sink when teams spend the first two weeks designing the perfect device. The rule is simple: by the end of lesson 4 every team needs a minimum working version. It does three things: it reads the sensor, shows the value in the Serial Monitor and lights a single LED when the value crosses a threshold. No box, no display, no Wi-Fi; but it produces real data and can be tested. For the noise team this means adding an if statement and an LED to the code of Measuring Light Intensity with an LDR. For the energy team, Night Light with Ldr is almost this version already; only the logic is reversed: the LED lights up not in the dark but when the lights are on, and the question "is the room empty?" arrives with a PIR in the next version. Every version after that brings exactly one change and goes into the test log:

1. Version 0, measurement: The sensor is read and the value is printed to the Serial Monitor once a second. The team sees the value change with a hand, light, sound or water.
2. Version 1, minimum working version: An estimated threshold and one LED. When the threshold is crossed, the LED lights up. This is the version shown at the checkpoint in lesson 4.
3. Version 2, calibration: After the field measurements, the threshold is chosen from data rather than a guess; for example, halfway between the empty-classroom value and the value during break.
4. Version 3, stable warning: When the value hovers around the threshold, the LED flickers. The fix is to average the last 10 readings or to use two separate thresholds for switching on and off.
5. Version 4, built for the user: The warning is shaped around the person affected by the problem: a three-colour light everyone can see in the cafeteria, a small LCD on the teacher's desk in a classroom. Boxing and placement happen in this version.

Checkpoint and final presentation criteria

For general criteria such as circuit, code, understanding, debugging and documentation, you can use the main rubric from the Arduino project rubric post as it is. In a PBL unit it's enough to add three criteria to it; they measure what a project assignment doesn't, but what this unit really teaches. The checkpoint happens in lesson 4 and looks only at the problem definition and the minimum working version; its purpose is to correct the direction, not to give a grade. In the final presentation all three criteria are scored. A prototype that stands out at the end of the unit can also go on to a science fair; for topic ideas see the science fair project ideas post.

• Problem (30 seconds): The sub-question and one sentence from the person you interviewed describing the problem.
• Measurement (45 seconds): Where, when and how many times you measured; a single table or chart.
• Live demo (45 seconds): The device crosses the threshold in front of the audience and gives its warning. Have a short demo video ready as a backup.
• Versions (30 seconds): One decision from the test log: "We changed the threshold because of this measurement."
• Recommendation (30 seconds): A concrete recommendation to the school (where, how many devices, who looks after them) and what you'd do with one more week.
• Questions (2 minutes): The teacher or the audience directs a question to a team member of their choice, so everyone must be able to explain every part.

What does BlueGrays do in this unit?

• Starter project with Project Finder: In lesson 2 the team answers three questions: Measure and sense for "What would you like to build?", Arduino Uno / Nano as the board and, for most classes, "I've built a few projects" as the experience. Next to the best match, the results screen may also show a free warm-up project you can start with the same parts. Details are in the Project Finder post.
• Understanding code with Understand the code: Copying the starter project's code and moving on doesn't work in PBL, because the team is going to change that code. The Understand the code tab first gives the "What does this code do?" summary, then the Step by step explanation and finally a Try it yourself task that asks for a single change. It's open to everyone on free projects and unlocks with Premium on Premium projects. We showed how to use it in the Understand the code post.
• Planning parts with Workshop › Parts (Premium): If you enter the parts in your classroom cupboard into Workshop › Parts with their quantities, the Projects You Can Build and Projects with Missing Components lists show which scenario can start today and which needs an order. Details are in the Arduino projects with the parts you have post.
• Your own sample project: Before the unit you can build one scenario yourself and share it via Learn > Forum > New Post in the Tutorial category: add photos of the circuit (up to 5 images), put in your code with Add code and link the related ready-made projects. The post is published in the language you write it in; send its link to the class group with Share. You can pass on ready-made projects the same way with Share on the project page. The steps are in the teaching with your own project post.
• Premium access for the class: For Premium starter projects such as Smart Irrigation Station and for Workshop › Parts, you don't need a separate subscription for every student; we explained the one-time, non-renewing educator packages that students redeem without adding a card in the Premium codes for a whole class post.

Know what the app doesn't do, too: BlueGrays has no class creation, no dashboard showing team progress to the teacher and no assignment feature. The problem card, team contract and test log stay on paper or in a shared document your school uses. The app carries the "how do I build it, what does the code do, which part is missing?" side of the unit; the "why this threshold, who benefits?" side is the team's job and yours. That split suits PBL anyway: the thinking stays with the team, not on the screen.

Common PBL pitfalls and how to fix them

Pre-unit checklist

• The driving question is written on a poster and up in the classroom.
• The 4 scenario cards (problem, possible sensor, starter project) are copied for every team.
• All 7 kits are counted; every sensor has been tried once and gives values in the Serial Monitor.
• The Arduino IDE and board driver are installed on the computers and the USB cables are tested.
• The starter projects open on students' phones or tablets; if Premium projects are used, the codes have been handed out.
• The problem card, team contract and test log forms are printed for every team.
• School leadership has approved the school walk and field measurements; measurement times for the cafeteria, corridor and garden are set.
• The audience for the final presentation (school leadership, school staff, another class) is invited and has a date.
• The PBL criteria table is printed for the checkpoint (lesson 4) and the final (lesson 8).

The real product of this unit isn't the device, it's the student's habit of "I measure first, then I decide"; the device sits on the desk as the evidence. On your first run you don't have to open all four scenarios; starting with two scenarios and six teams teaches the same loop. If you want to build the starter projects once yourself before taking them to class, just download the BlueGrays app and try Night Light with Ldr with its circuit diagram, code and Understand the code steps.