Finish, Test, and Showcase Your Arduino Invention

You have built more than a gadget. You have built a machine with inputs, outputs, rules, memory, and a history of failed tests and improvements.

Today you will prove that your invention works for someone besides you. A user will try it while you watch without rescuing them. Then you will make one small revision based on evidence, rerun the same tests, and give a two-minute engineering demonstration. The goal is not perfection. The goal is a working project you can explain honestly.

At a glance

What you will learn

• How to test whether a project works repeatedly, not just once.
• How to observe a user without immediately telling them what to do.
• How to turn a vague reaction into useful engineering evidence.
• How to make one small revision and rerun the original test.
• How to explain an input, output, variable, condition, loop, and function in your own code.
• How to present a debugging story that shows persistence and reasoning.

Before you begin

Complete Lesson 11: Build and Debug Your Arduino Capstone v1 first. Bring the working version 1.0 project, its known-good sketch, pin map, test table, wiring photos, and maker notebook.

Your project may be a Room Sentinel, Secret-Code Safe, Reaction Game, Scorekeeper, Pet-Care Reminder, or another approved invention. It must still meet the Lesson 8 boundaries: USB-powered, solderless, safe Student Kit parts, at least two inputs, at least two outputs, and one clear must-have rule.

Choose one family member or friend as the user. The best tester is someone who has not watched every build step. Tell them the purpose in one sentence, but do not teach every button or rule first.

Do not move the capstone into Tinkercad. Today tests the physical invention and how a person understands it. Arduino’s Getting Started guide reviews the model you now know well enough to explain.

What you need

Required components

Optional components

• Phone or camera for four evidence images and an optional short video.
• Tape, labels, markers, cardboard, or rubber bands for one small revision.
• Printed code with four highlighter colors: input, decision/memory, output, and function.
• One-page user-guide paper.

Tools

None for electronics. Scissors and tape may be used for labels. Adult help is required for craft knives or hot glue; neither is necessary.

Computer/software requirements

• Arduino IDE 2 with Arduino Uno and its port selected.
• The final known-good sketch saved before any showcase revision.
• Serial Monitor at the correct baud rate if raw readings are part of the demonstration.

Safety and setup notes

• Keep the capstone USB-powered, low-voltage, solderless, and on a dry table.
• Unplug USB before moving wires, changing the enclosure, or touching a servo linkage.
• The project remains a tabletop prototype. It must not control a real lock, appliance, heater, security system, pet equipment, or food/water container.
• A toy safe must always open by hand. A servo must move freely without buzzing, stalling, heating, or pinching.
• Keep every LED resistor and common ground intact. Do not hide uncertain wiring under cardboard.
• The adult should stop the test for heat, repeated resets or disconnections, servo stress, a short, or a physical hazard. Cosmetic imperfection is not an emergency.

Build overview

Protect known-good version
  ↓
Run three repeatability tests
  ↓
Watch one user without rescuing
  ↓
Choose one evidence-based revision
  ↓
Repeat the original tests
  ↓
Explain and showcase

Step-by-step build instructions

Step 1: Protect the working version

1. Open the Lesson 11 known-good sketch.
2. Use Save As to make a showcase copy such as reaction_game_final or room_sentinel_final.
3. Photograph the working project from above before moving wires or cardboard.
4. Write the must-have rule and exact pin map at the top of the test card.

Checkpoint: you have a code file and photo that can restore the Lesson 11 version. Do not begin with a last-minute feature.

Step 2: Run the final safety and repeatability check

1. With USB unplugged, inspect 5V and GND, LED resistors, component orientation, loose jumpers, and servo clearance.
2. Reconnect and run the must-have test three times from the same starting condition.
3. Power-cycle once: unplug, wait five seconds, reconnect, and confirm safe startup.
4. Run one edge case: wrong code, false start, repeated press, triggered sensor at startup, reset at zero score, or acknowledge while inactive.

Checkpoint: either it passes or you have one specific symptom. “It acted weird” is not specific enough.

Step 3: Prepare one unassisted user test

PROJECT NAME:
THIS PROJECT IS SUPPOSED TO:

YOUR TASK:
Try to ____________________________________________.

PLEASE THINK ALOUD:
What do you think each button, light, sound, or moving part means?

BUILDER OBSERVES—DOES NOT HELP:
Where did the user pause?
What did the user press or expect?
What worked without explanation?
What surprised the builder?

Checkpoint: describe the goal, not the button sequence. Say “Try to unlock the toy safe,” not “Press 1, then 3, then 2.”

Step 4: Watch the user without rescuing

1. Start in the normal beginning state.
2. Read only the one-sentence purpose and task.
3. Stay quiet for the first attempt unless safety requires intervention.
4. Record actions, pauses, guesses, and results—not judgments.
5. Ask afterward: “What did you think would happen?” and “What would have made that clearer?”

Checkpoint: record one direct observation, such as “The user pressed the red light because it looked like a button.”

Step 5: Choose one revision from the evidence

Checkpoint: “The user/test showed ___. I will change ___. I predict ___.” Choose one revision only.

Step 6: Make the revision and rerun the same tests

1. Save the pre-revision sketch and photograph the before condition.
2. Make one code, wiring, label, threshold, rule, or mechanical change.
3. Rerun the exact user task yourself.
4. Repeat the must-have test three times and the same edge case.
5. Invite the same user to try again if time permits without extra hints.

Checkpoint: record before and after. If it creates a new failure, restore known-good and choose a smaller change.

Step 7: Prepare a two-minute engineering demonstration

1. Problem and user: “I built ___ for ___ because ___.”
2. Demonstration: show one normal cycle.
3. Circuit: point to two inputs and outputs with pins.
4. Code: point to one variable, condition, loop, and function.
5. Debugging story: explain one mismatch and smallest test.
6. Revision: show what the user did, what changed, and the retest result.

Checkpoint: demonstrate once without reading full paragraphs. Notes are allowed.

Step 8: Capture the final evidence package

1. Finished-project photo in use.
2. Overhead wiring photo plus final pin map.
3. Code screenshot showing constants, setup(), loop(), state/score variable, and one function.
4. Before/after revision photo or notebook table.

Optional: record a 20–30 second demonstration video showing the problem, normal cycle, edge case, and named improvement.

Code

Use your own final capstone code. Reaction Game and Secret-Code Safe makers should preserve the complete Lesson 10 branch; other makers should preserve the integrated Lesson 11 sketch. Do not replace a working capstone merely for uniformity.

The Room Sentinel reference below shows the expected organization. Replace threshold and angles with your tested values.

#include <Servo.h>

const int ARM_BUTTON_PIN = 2;
const int LIGHT_SENSOR_PIN = A0;
const int PIEZO_PIN = 8;
const int SERVO_PIN = 9;
const int ARMED_LED_PIN = 10;
const int ALARM_LED_PIN = 11;

// Replace these with evidence from your own tests.
const int DARK_THRESHOLD = 400;
const int REST_ANGLE = 30;
const int ALERT_ANGLE = 110;

bool isArmed = false;
bool buttonWasPressed = false;
Servo alertServo;

void setup() {
  pinMode(ARM_BUTTON_PIN, INPUT_PULLUP);
  pinMode(ARMED_LED_PIN, OUTPUT);
  pinMode(ALARM_LED_PIN, OUTPUT);
  pinMode(PIEZO_PIN, OUTPUT);
  alertServo.attach(SERVO_PIN);
  alertServo.write(REST_ANGLE);
  Serial.begin(9600);
}

void loop() {
  bool buttonIsPressed = digitalRead(ARM_BUTTON_PIN) == LOW;
  if (buttonIsPressed && !buttonWasPressed) {
    isArmed = !isArmed;
    delay(30);
  }
  buttonWasPressed = buttonIsPressed;

  int lightValue = analogRead(LIGHT_SENSOR_PIN);
  bool roomIsDark = lightValue < DARK_THRESHOLD;

  Serial.print("Armed: ");
  Serial.print(isArmed);
  Serial.print(" | Light: ");
  Serial.print(lightValue);
  Serial.print(" | Dark: ");
  Serial.println(roomIsDark);

  if (!isArmed) {
    showDisarmed();
  } else if (roomIsDark) {
    showAlarm();
  } else {
    showArmedAndReady();
  }
  delay(100);
}

void showDisarmed() {
  digitalWrite(ARMED_LED_PIN, LOW);
  digitalWrite(ALARM_LED_PIN, LOW);
  noTone(PIEZO_PIN);
  alertServo.write(REST_ANGLE);
}

void showArmedAndReady() {
  digitalWrite(ARMED_LED_PIN, HIGH);
  digitalWrite(ALARM_LED_PIN, LOW);
  noTone(PIEZO_PIN);
  alertServo.write(REST_ANGLE);
}

void showAlarm() {
  digitalWrite(ARMED_LED_PIN, LOW);
  digitalWrite(ALARM_LED_PIN, HIGH);
  tone(PIEZO_PIN, 900);
  alertServo.write(ALERT_ANGLE);
}

What the important code means

• Variables and constants: constants connect names to pins and tested values. isArmed, gameState, score, or codeStep remembers something changeable.
• setup(): runs once after power-up and begins in a predictable, safe state.
• loop(): repeats the input → decision → output cycle. Some projects also use a for loop for repeated effects.
• Inputs and outputs: point to two physical inputs and reading lines, then two outputs and control functions.
• Condition: an if, else if, or else chooses behavior. Explain the question in ordinary language.
• Function: a named function groups one job such as alarm, point, unlock, or reminder clear.
• Final audit: one setup(), one loop(), no duplicate pin assignments, no abandoned test code changing outputs, and a clearly named final file.

See Arduino’s Getting Started guide and Debugging Fundamentals.

Make it work

1. It meets the Lesson 8 must-have rule.
2. It uses at least two inputs and two outputs.
3. It starts safely after a USB power cycle.
4. It passes the same must-have test three times.
5. It handles one documented edge case safely and fairly.
6. A user can attempt the task without step-by-step coaching.
7. One evidence-based revision is documented and the original test still passes.
8. The student explains an input, output, variable, condition, loop, function, and debugging decision.

A project may earn strong marks even if a nonessential feature remains unfinished. Understanding, evidence, persistence, and iteration matter more than polish.

Understand it

1. What did your user do that surprised you, and what evidence did it provide?
2. Which variable remembers something after release?
3. State one if condition as a true/false question.
4. What job does your loop() or a for loop repeat?
5. Which function could you test alone, and what would prove it worked?

Required “change it” challenge

Desired outcome: make one final revision based on something a user or repeatability test actually revealed.

Constraints: name the observed problem first; preserve known-good; change one subsystem or user detail; predict; repeat the exact must-have test three times; update documentation if circuit or code changed. Do not add a whole new feature.

1. Look for where the user paused, guessed, pressed twice, covered a sensor, ignored a light, or misunderstood a sound.
2. Choose the smallest response: label, position, duration, threshold, rule, loose wire, or servo angle.
3. For code, identify the exact constant, condition, or function before editing.
4. For physical changes, unplug and photograph before.
5. A good revision has clear before/after evidence without breaking the original requirement.

Parent guidance: ask for the observation and prediction first. Resist suggesting a bigger feature. Step in for safety, threatened known-good, or 15–20 minutes without a controlled retest.

Optional enhancements

Try this

Give the invention a memorable name and logo without covering controls, sensors, or wiring.

Challenge

Write a one-page user guide: purpose, how to start, what controls and outputs mean, and how to reset safely.

Stretch

Plan version 2 with exactly one new capability. State its usefulness, new risk, and first subsystem test. Do not dismantle the working capstone today.

Debugging guide

Use the Debugging Ladder. For outside help, collect photos, board model, OS, IDE version, board/port, full code, meaningful errors, expected and actual behavior, and exact steps. Do not post personal information publicly.

Recap

You finished Level 1 as an inventor, tester, debugger, and explainer. Your capstone combined real inputs and outputs, followed code rules, survived repeated tests, met a real user, and changed because of evidence. Perfection was never the goal; understandability, testability, and improvement were.

Show what you learned

• What problem did your invention solve, and for whom?
• What did a user do that surprised you?
• What changed because of the user or repeatability test?
• What failed during the course, and what smallest test helped?
• Explain one input, output, condition, loop, variable, and function.
• What one version 2 capability would justify added complexity?

Attach the final photo, wiring/pin map, code screenshot, and before/after revision record.

What’s next

Return to the Level 1 overview and compare what you can now explain with Lesson 1. Then visit the Robotics Track roadmap as Levels 2–6 take shape. Your next independent project should introduce one new challenge—not an entire mystery kit.

Before buying anything, write the next project in the same form: user/problem, two inputs, two outputs, must-have rule, first risk, and smallest subsystem test. Keep the Components guide, Debugging Ladder, and maker notebook as permanent tools.

Parent guide

Prepare

• Preserve the Lesson 11 known-good project and code. Charge the camera if documenting.
• Invite one user who can follow a short task without technical knowledge.
• Print the test card, evidence checklist, and assessment table.
• Clear a safe demonstration space with USB power and no rush.

Child independence

Let the child run safety and repeatability checks, define results, watch the user, record observations, choose and execute the revision, retest, photograph evidence, and demonstrate their own circuit and code.

Resist taking over

Do not coach the first user attempt, repair cosmetic issues unless they affect safety or function, or turn the final revision into your design. Let the student present an honest debugging story.

Step in

Step in for heat, shorts, USB failure, servo stress, unsafe movement, cutting risk, or threatened known-good. If the essential project fails after diagnosis, help demonstrate the last known-good subsystem and explain the failure.

Assessment

Score each category from 0–3. A functioning gadget is only one category.

Total: 15 points. Treat 11–15 as strong mastery, 7–10 as solid progress with specific next skills, and 0–6 as a reason to revisit foundations. More important than the number: write one sentence naming the student’s strongest engineering habit and one naming the next skill to practice.

Further resource: Arduino: Getting Started with Arduino