Build and Debug Your Arduino Capstone v1

Today the separate pieces become an invention.

Your buttons, sensors, lights, sounds, servo mechanism, and rules may already work one at a time. The challenge is making them work together without losing track of what failed. Professional engineers solve that problem by integrating in stages: prove one subsystem, add one more, and keep evidence. Your goal is not a polished final product. Your goal is a working, explainable version 1.0.

At a glance

What you will learn

• How to combine at least two inputs and two outputs without debugging everything at once.
• How to create and use a project-specific pin map.
• How to preserve a known-good sketch before changing it.
• How to test outputs, inputs, and the main rule as separate subsystems.
• How to describe a failure as expected versus actual behavior.
• How to make one improvement because of evidence, then rerun the original test.

Before you begin

Bring your completed Lesson 8 capstone plan, your known-good Lesson 9 servo sketch if your project moves something, and your known-good Lesson 10 rules sketch if your project uses reaction, scoring, or secret-code logic.

Your version 1.0 must have:

• At least two inputs.
• At least two outputs.
• One must-have rule written as: “When ___ happens, the Arduino will ___.”
• One normal test and one edge-case test.
• One recorded failure, test, and fix—or a recorded test that proved the suspected part was not the problem.

Do not simulate the whole capstone in Tinkercad. Today’s risks are physical: loose ground wires, pin conflicts, servo load, button placement, sensor orientation, and cardboard geometry. Use the real Uno and keep the enclosure open until the electronics pass.

Arduino’s official upload guide recommends checking compile errors, board/port selection, the physical connection, data cable, and console output in order. Use it and the course Debugging Ladder if the Uno stops uploading.

What you need

Required components

Optional components

• Small cardboard box, tape, rubber bands, paper fasteners, craft sticks, string, and markers for a rough enclosure.
• Phone or camera for wiring and test-evidence photos.
• Printed pin labels or masking tape.
• The complete Room Sentinel reference circuit in Section 10 if that is your capstone.

Tools

None for the electronics. Scissors and tape are optional. 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.
• Serial Monitor at 9600 baud for sensor or input diagnosis.
• One saved known-good sketch plus a clearly named new file such as room_sentinel_v1, reaction_game_v1, or pet_reminder_v1.

Safety and setup notes

• Keep the project USB-powered, low-voltage, solderless, and on a dry table. Unplug before moving wires.
• Do not connect the project to a real lock, appliance, wall power, pet collar, food or water container, heater, door security system, or anything safety-critical. These are tabletop prototypes.
• Every LED needs its own resistor. Every subsystem must share Arduino ground, but 5V and ground must never share a connected row.
• Use only one small, safely tested servo. If it buzzes, stalls, becomes warm, resets the Uno, or forces cardboard, unplug immediately and remove its mechanical load.
• Keep the enclosure open until all subsystem tests pass. A box that hides loose wires is not an improvement.
• The parent should step in for power shorts, component heat, servo stress, cutting tools, or a board that disappears from the computer. The student should own pin labels, code changes, tests, photos, and the bug log.

Build overview

Integration follows one rule: never add an untested mystery to another untested mystery.

Bare Uno works
  ↓
Each output works alone
  ↓
Each input reports correctly
  ↓
One input controls one output
  ↓
Full must-have rule works
  ↓
Enclosure is added and the same tests still pass

Use the established course pin map unless your Lesson 8 plan documented a conflict:

If your pin map differs, write the difference before wiring it. A documented change is engineering; a forgotten conflict is a bug.

Step-by-step build instructions

Step 1: Freeze the last known-good versions

1. Open each working sketch you plan to reuse.
2. Use File → Save As to make a copy with _known_good in the name.
3. Create a separate v1 sketch for today. Never experiment inside the only working copy.
4. Copy your must-have rule and pin map into a comment at the top.

Checkpoint: name the file you will edit and the file you will not touch.

Step 2: Make a project-specific pin and test table

Checkpoint: every part has one pin and one smallest test. D9 appears only once.

Step 3: Run the bare-board preflight

1. Disconnect all breadboard and servo wires.
2. Upload Lesson 1’s built-in Blink sketch.
3. Confirm power, Arduino Uno and correct port, successful upload, and blinking built-in LED.
4. Reconnect the capstone only after this passes.

Checkpoint: if Blink fails, the capstone circuit is not yet the problem. Follow Arduino’s upload troubleshooting sequence.

Step 4: Build and test outputs one at a time

1. Connect and label the ground rail first.
2. Add Output 1 only and run its known-good test.
3. Record pass or fail and fix it before adding Output 2.
4. Add Output 2 and rerun both tests.
5. For a servo, test without cardboard first, then with the light linkage. Stop for buzz, stall, heat, or reset.

Checkpoint: every output works alone and after the next output is connected. If adding one breaks another, inspect ground, pin conflicts, and servo power or load before editing logic.

Step 5: Add and test inputs one at a time

1. Add Input 1. For a button, confirm released = HIGH, pressed = LOW. For a sensor or knob, print its raw value.
2. Record two real input states.
3. Add Input 2 and repeat without connecting it to the full rule.
4. Label crowded input wires at both ends.

Checkpoint: read both inputs independently and predict their values. Fix floating, stuck, or backward inputs before integration.

Step 6: Combine one input with one output

Choose the simplest useful pair: arm button → green LED, code button → feedback light, player button → player light, dial → Serial setting, or acknowledge button → quiet piezo.

1. Start from the most similar known-good code.
2. Group pin constants at the top.
3. Put one testable job in a named function such as showAlarm(), awardPoint(), unlockSafe(), or clearReminder().
4. Upload and run the same test three times.

Checkpoint: the pair passes three times. Save this version.

Step 7: Add the full must-have rule

1. Read the rule aloud before upload.
2. Predict outputs for normal, no-action, and edge cases.
3. Upload and test one case at a time.
4. Record expected and actual behavior without rewriting history.

Checkpoint: the capstone meets its one must-have rule. Optional features remain disconnected.

Step 8: Add the rough enclosure and rerun tests

1. Unplug USB and secure only parts that work.
2. Keep sensors, buttons, servo motion, and USB access unobstructed.
3. Reconnect and repeat normal and edge-case tests.
4. If enclosure causes failure, remove it and compare.

Checkpoint: version 1.0 passes three repeated tests with the enclosure—or you isolated which enclosure change causes failure.

Code

Keep the complete Lesson 10 Reaction or Secret-Code sketch if that is your capstone. The following is a complete Room Sentinel v1 reference. Replace DARK_THRESHOLD, REST_ANGLE, and ALERT_ANGLE with values tested in Lessons 6 and 9. If darkness produces higher readings, reverse the comparison as described in Lesson 6.

Wire arm button D2 to GND with INPUT_PULLUP; phototransistor collector to 5V and emitter to A0 with 10 kΩ from A0 to GND; piezo D8 to GND; servo D9 signal with 5V/GND power; and LED long legs through separate 220 Ω resistors to D10/D11, short legs to GND.

#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: every pin has one readable name. Threshold and angles come from prior tests. isArmed remembers state after release.
• setup(): prepares pins, attaches the servo, places it safely at rest, and starts Serial Monitor.
• loop(): reads inputs, toggles armed state on a new press, prints evidence, and chooses one output behavior.
• Inputs and outputs: D2 and A0 are inputs; D8–D11 control sound, movement, armed status, and alarm status.
• Button edge: buttonIsPressed && !buttonWasPressed means pressed now but not last time.
• Conditions: the alarm happens only when armed and the sensor crosses its tested threshold.
• Functions: each output function represents one independently testable state.

For other capstones, keep this organization: pin constants, state/score variables, setup(), loop() to read inputs and choose a rule, and small named output functions.

See Arduino’s Debugging Fundamentals and upload troubleshooting guide.

Make it work

1. The Uno uploads reliably with the full circuit.
2. At least two inputs pass separate tests.
3. At least two outputs pass separate tests.
4. One input/output pair passes three times before full integration.
5. The project meets the Lesson 8 must-have rule three times.
6. One edge case produces the stated safe or fair response.
7. The student identifies the last known-good sketch and explains one recorded test, failure, and result.

The capstone does not need to look finished. Working, testable, and explainable beats hidden wires and decorative cardboard.

Understand it

1. Why test each output before connecting the full rule?
2. What is your state, score, threshold, or code-step variable remembering?
3. If an enclosure breaks the project, how can removing it be diagnostic evidence?
4. What is the difference between a symptom and evidence?
5. Which known-good sketch tests your riskiest subsystem?

Required “change it” challenge

Desired outcome: improve one real weakness discovered by a test: threshold, sound, status light, rule, servo position, button, or label.

Constraints: write evidence first; change one value, rule, wire, label, or mechanical detail at a time; predict the result; repeat the exact original test; record before and after. Do not add an unrelated feature.

1. Write: “During test ___, I expected ___, but actually ___.”
2. Circle the smallest subsystem: power/upload, input, rule, output, or mechanism.
3. Change the smallest thing that tests your explanation.
4. Rerun the original must-have test. A fix that breaks the main rule is not yet an improvement.

Parent guidance: require evidence. Ask, “What single test makes you think that?” and “How will we know it helped?” Let the child preserve the working version and change one thing. Step in for safety or after 20 minutes without a new test.

Optional enhancements

Try this

Label every control and status output without moving wires: ARM, RESET, PLAYER 1, ACKNOWLEDGE, READY, ALARM, or OPEN. Ask someone to find the correct control without explanation.

Challenge

Invite one family member to run the normal test while you remain silent. Record where they hesitate, press twice, cover a sensor, or misunderstand a light.

Stretch

Create a “version 2 later” list with no more than three ideas. Name each extra test or component. Do not build it today.

Debugging guide

Use the Debugging Ladder in order. For help, collect overhead and side photos, board model, OS, IDE version, selected board/port, full code, first meaningful errors, raw readings, and expected versus actual behavior.

Recap

You built version 1.0 by integrating known-good subsystems instead of guessing at one giant circuit. You proved outputs, inputs, one pair, the must-have rule, an edge case, and one evidence-based improvement.

Show what you learned

• What was the smallest useful test?
• What are your two inputs and outputs, including pins?
• What did you expect and what actually happened?
• What evidence caused the improvement?
• Did the must-have test still pass?
• Explain one state variable, condition, function, or connection.

What’s next

Next is Lesson 12: Capstone Showcase and Engineering Review. A user will try version 1.0, you will watch without rescuing them, and you will make one final evidence-based revision. Preserve today’s known-good files, pin map, test table, photos, and enclosure.

Parent guide

Prepare

• Put out the exact Lesson 8 parts, notebook, known-good sketches, cardboard, labels, and a known data cable.
• Confirm bare-board Blink if connection reliability is uncertain.
• Display the Debugging Ladder and a pass/fail table.
• Keep optional decorations and extra components aside until v1 passes.

Child independence

Let the child map pins, label wires, run subsystem sketches, record values, integrate functions, photograph evidence, name expected versus actual results, choose the improvement, and rerun the original test.

Resist taking over

Do not rebuild a messy breadboard merely for neatness, paste the final program, or change several suspicions at once. Ask, “What single part are we testing?”

Step in

Step in for shorts, heat, USB disconnection, servo stress, cutting risk, or damage. After 20 minutes without new evidence, simplify to known-good and collect the troubleshooting evidence in Section 15.

Assessment

Ask for a two-minute handoff: user/problem, inputs, outputs, must-have rule, known-good subsystem, surprising test, and improvement evidence. Score understanding, safety, persistence, and iteration equally.

Further resource: Arduino Support: If Your Sketch Doesn’t Upload