Choose and Plan Your Arduino Invention

For the next four lessons, you will not be following one person’s finished project. You will be making your invention.

Real inventors do not begin by dumping every component onto a breadboard. They choose a person to help or entertain, write one clear must-have rule, prove a small hard part, and improve from evidence. Today you will do exactly that. By the end, you will have one project choice, a simple plan, and one working mini-test.

At a glance

What you will learn

• How to turn an idea into a project that can actually be built and tested.
• How to distinguish a must-have requirement from a “maybe later” feature.
• How to name inputs, outputs, and the rule that connects them.
• How to write pseudocode: the plan for code written in ordinary language.
• Why testing one small subsystem is smarter than connecting everything at once.
• How a user’s needs can improve an invention.

Before you begin

This is Lesson 8 of the course. Complete the button, sound, dial, light-sensor, and temperature-sensor lessons first: Lesson 2, Lesson 4, Lesson 5, Lesson 6, and Lesson 7. You are not expected to remember every line of code. You are expected to know that an Arduino reads inputs, follows rules, and controls outputs.

Keep the Components guide, Debugging Ladder, and Maker notebook nearby. Every approved project uses only the Arduino Student Kit, is solderless, and runs from USB power. Do not buy a keypad, RFID reader, battery pack, screen, or extra kit for this capstone.

Do not use Tinkercad as a replacement for this planning session. A 10-minute simulation is optional only if you need to rehearse a button and LED. Your required mini-test must happen on the real Uno and breadboard, because the final project will need physical wiring, code, and debugging.

Arduino describes the basic model as input → processing → output in its What Is Arduino? guide. Your capstone plan will use that model.

What you need

Required components

Optional components

• Exact Student Kit parts selected for your mini-test: extra buttons, LEDs and resistors, potentiometer, phototransistor, TMP36, tilt sensor, or small servo.
• Cardboard, tape, scissors, markers, and recycled boxes for a rough enclosure sketch. Adult help is needed for craft knives or hot glue; neither is required.
• A family member to be your first customer.

Tools

None for the electronics. Scissors and tape are optional for the enclosure sketch.

Computer/software requirements

• Arduino IDE 2 with Arduino Uno and its port selected.
• Serial Monitor at 9600 baud if your chosen mini-test uses a sensor.
• Optional Tinkercad: current browser and a free Autodesk account. It is a rehearsal tool, not proof that the real circuit works.

Safety and setup notes

• Unplug the Uno before changing wires. Keep this project USB-powered and solderless.
• Do not connect the capstone to wall power, household appliances, locks, pets, food or water containers, or anything that could cause harm or damage. It is a tabletop prototype.
• A cardboard “safe” must be a toy container only. It must never trap a person, pet, or valuable item, and it must always be possible to open it by hand.
• Do not attach a servo or moving part until Lesson 9. For now, use drawings or cardboard mock-ups; never force a servo arm by hand.
• Use a 220 Ω resistor for every LED. Adult help is appropriate for a possible 5V/ground short, a warm component, a noisy piezo, or any cutting tool.
• The parent’s most important job today is to keep the scope safe and small. A project that works, is testable, and has one honest improvement is better than a giant plan that never leaves the notebook.

Build overview

This lesson’s build is a plan plus proof. The plan says what your invention should do. The proof is a tiny circuit that proves one input can make an output respond.

Person has a need or wants a game
  ↓
Input happens → Arduino reads it → code follows a rule → outputs respond → person tests it

Your final project must meet these four boundaries:

1. It uses at least two inputs and at least two outputs by Lesson 11.
2. It uses only safe, 5V, solderless Student Kit parts and USB power.
3. It has one clear must-have rule that a stranger can test.
4. It can be built in four lessons: design now, mechanism next, rules the lesson after, full build and debug, then showcase.

An input is something the Arduino notices: a button, knob, light sensor, temperature sensor, or tilt sensor. An output is something it does: LED, sound, servo movement, or a printed message. The rule is the decision between them.

Step-by-step build instructions

Step 1: Choose one capstone mission

Read the choices below. Pick one that sounds fun enough to keep improving, but small enough to finish. You may choose “Another invention” only if it meets all four boundaries in the build overview.

Checkpoint: say this sentence aloud: “I am making a ___ for ___, and the one thing it must do is ___.” If it has three different “must” ideas, choose only one for now.

Step 2: Write the must-have and the “later” list

Copy this planning sheet into your maker notebook. Fill it in with short, specific answers. A drawing is welcome, but it cannot replace the words.

PROJECT NAME:
USER (who will try it?):
PROBLEM OR GAME:

MUST-HAVE RULE:
When ____________________________________________,
the Arduino will __________________________________.

INPUT 1:                    INPUT 2:
INPUT 3 (only if needed):

OUTPUT 1:                   OUTPUT 2:
OUTPUT 3 (only if needed):

PARTS I ALREADY HAVE:

ONE FEATURE FOR LATER (not this build):

HARDEST RISK / QUESTION:

FIRST MINI-TEST:
If I ____________________, I expect ____________________.

EVIDENCE OF SUCCESS:
I will know it worked when ______________________________.

Checkpoint: circle the must-have rule. Put a box around every “later” feature. If your must-have cannot be tested in one sentence, make it smaller.

Step 3: Write pseudocode before Arduino code

Pseudocode is a plain-language version of a program. It is not supposed to compile. It is supposed to help you catch a confusing rule before wires and code get messy.

Start with the project safe and waiting.
Read the inputs.
If the important rule is true,
  make the warning/game/reminder outputs happen.
Otherwise,
  show the waiting/normal output.
Repeat.

Example for Room Sentinel:

Start unarmed with a green light.
Read the arm button and light sensor.
If the project is armed and the light changes past my tested threshold,
  flash red, make a warning sound, and raise the flag.
Otherwise,
  stay calm and show green.
Repeat.

Checkpoint: underline the input words, circle the output words, and box the rule word if. If you cannot tell which thing is an input or output, ask the parent to read your plan back exactly as written—do not ask them to redesign it.

Step 4: Choose the first risk to prove

Do not try to prove the entire invention today. Choose the smallest important question that could ruin the project if it fails.

Checkpoint: write the mini-test as: “If I ___, I expect ___.” Do not build more than the test requires.

Step 5: Build the universal button-to-indicator proof

This reusable mini-test works directly for Secret-Code Safe, Reaction, Scorekeeper, and Pet-Care projects. It also works for Room Sentinel because it can prove the arm/disarm button before you add its sensor. Build it even if you later choose a different test; it confirms that your Uno can read a user action and control two outputs.

1. Put the tactile button across the breadboard’s center trench. Its legs must not all land in one connected strip.
2. Connect one button side to Arduino D2. Connect the opposite button side to Arduino GND. This project uses the Arduino’s internal pull-up resistor, so do not add an external resistor.
3. Place the LED with legs in different rows. Connect its short leg to ground. Connect its long leg through a 220 Ω resistor to Arduino D9.
4. Connect piezo positive to Arduino D8 and piezo negative to ground. If your piezo has no plus mark, either orientation is fine for this simple test.
5. Before plugging in USB, trace: D2 → button → GND, D9 → resistor → LED → GND, and D8 → piezo → GND.
6. Upload the complete proof code in the next section. Press the button several times, leaving a second between presses.

Checkpoint: while the button is held, the LED should light and the piezo should sound. When it is released, both should stop. If this mini-test does not work, use Section 15 before adding capstone parts.

Step 6: Interview your first customer and revise one sentence

Ask a parent, sibling, or friend: “If you had this project, what would you expect it to do?” Do not explain it first. Listen for one unclear expectation.

Revise one sentence in your must-have rule or test plan. Examples: “faster” becomes “within one second”; “easy to use” becomes “a younger sibling can press one labeled button”; “secure” becomes “a wrong code gives a red light and no servo movement.”

Checkpoint: record the person’s comment and your one revised sentence. You are ready for the next four lessons when your plan is clearer, not when it is fancier.

Code

const int BUTTON_PIN = 2;
const int LED_PIN = 9;
const int PIEZO_PIN = 8;

void setup() {
  pinMode(BUTTON_PIN, INPUT_PULLUP);
  pinMode(LED_PIN, OUTPUT);
  pinMode(PIEZO_PIN, OUTPUT);
}

void loop() {
  bool isPressed = digitalRead(BUTTON_PIN) == LOW;

  if (isPressed) {
    digitalWrite(LED_PIN, HIGH);
    tone(PIEZO_PIN, 440);
  } else {
    digitalWrite(LED_PIN, LOW);
    noTone(PIEZO_PIN);
  }
}

What the important code means

• Variables and constants: the named pin constants make the physical wiring easy to read. isPressed is a bool, a variable that holds true or false.
• setup(): this runs once and prepares the button as an input and the LED/piezo as outputs.
• loop(): this repeats quickly: check the button and make the outputs match the answer.
• Inputs and outputs: D2 button is the input. D9 LED and D8 piezo are outputs. In your capstone, you will add more inputs and outputs around the same idea.
• The important twist: INPUT_PULLUP makes an unpressed button read HIGH and a pressed button read LOW, because the button connects D2 to ground. The == LOW part translates that electrical fact into a helpful true/false name: isPressed.
• The condition: the if block is the “rule is true” branch. The else block is the waiting branch.

This is a subsystem proof, not final capstone code. Keep its readable names and one-change-at-a-time testing habit, but do not add every future feature to it today. Lesson 9 adds a tested servo mechanism where your project needs one; Lesson 10 builds the game, code, or score rules.

Arduino’s What Is Arduino? guide explains the board as a programmable system that reads inputs and controls outputs. The official Input Pullup Serial example explains why a button wired to ground reads LOW when pressed.

Make it work

Today succeeds when all of these are true:

1. You chose one capstone, one named user, and one must-have rule.
2. Your plan lists at least two future inputs and two future outputs.
3. You wrote pseudocode before trying to make final code.
4. You named one risk and made one mini-test that answers it.
5. The button-to-indicator test works: hold button → light and sound; release → both stop.
6. You can explain why your project is small enough to finish in four lessons.

Understand it

1. What is the difference between an input, an output, and the rule in the middle?
2. Why is “it has lots of cool features” not a testable requirement?
3. In the proof code, why does pressing the button make isPressed true even though the Arduino reads LOW?
4. Which risk did you choose to test first, and why is it more useful than building everything at once?
5. If a person says “make it easier,” what question could you ask to turn that into a testable requirement?

Required “change it” challenge

Desired outcome: make one purposeful requirement change before you wire a bigger project. Choose one: quieter, faster, fairer, more visible, easier for a sibling, or harder to unlock. Update both your pseudocode and your test plan to match.

Constraints: keep the same capstone mission and must-have rule; explain one change to code and one change to hardware or user experience; run one small test of the revised idea; record what evidence would show that the revision helped. Do not solve the challenge by adding a random feature.

Hints:

1. Quieter might mean a short chirp instead of a continuous tone; code changes tone() timing, and the user experience changes from annoying to noticeable.
2. Fairer might mean both reaction-game buttons have the same LED and wire length; code needs a false-start rule, and hardware needs clearly labeled identical buttons.
3. Easier for a sibling might mean one large arm button and a colored status LED; code gets a clear waiting state, and hardware gets a label or larger target.
4. Harder to unlock might mean a longer secret code; code remembers more inputs, and hardware may need a clear reset indicator so a user knows when to start over.

Parent guidance: require a before and after sentence: “Before, ___; after, ___.” Then ask, “What has to change in code? What has to change where a person touches or sees it?” Let the child reject an idea that makes the project too large. A productive struggle is 10–15 minutes of choosing a measurable improvement and designing a fair mini-test. Step in if the new requirement needs parts outside the kit, more than two new capabilities, unsafe access control, or 15–20 minutes pass without a specific test. You are a customer and safety editor, not the inventor.

Optional enhancements

Try this

Sketch a cardboard enclosure on paper. Label where a user will press, look, hear, and where the USB cable exits. Hint: a good enclosure protects wires without covering a sensor or trapping a moving servo arm.

Challenge

Give the planning sheet to a family member without explaining it. Ask them to point to the input, rule, and output. Revise the one part they misunderstand. This is a user test, not a quiz for them.

Stretch

Make a one-page test card for Lesson 11. Include three rows: test action, expected result, and actual result. Add one edge case, such as two players press at once, someone enters a wrong code, or the room is already dark when the project is armed.

Debugging guide

Use the Debugging Ladder for a failed physical mini-test. For planning trouble, use a parallel ladder: user → must-have rule → one input → one output → tiny test → evidence. Do not add components until the smallest next question has an answer.

Recap

You became the project designer. You chose a feasible invention, named a user and must-have rule, separated inputs from outputs, wrote pseudocode, proved a tiny subsystem, and improved a requirement based on a real person’s feedback. Those are engineering skills—not just pre-project paperwork.

Show what you learned

In your maker notebook, complete these prompts:

• My invention is for ___, and its must-have rule is ___.
• What are my two inputs and two outputs?
• What was the riskiest part, and what mini-test did I run?
• What did I change after a customer comment or test?
• What failed, if anything, and how did I diagnose it?
• Explain in your own words why INPUT_PULLUP makes the button read LOW when pressed.

What’s next

Next, in Lesson 9: Build a Servo Gate or Safe Latch, you will learn to move a real mechanism. Secret-Code Safe, Room Sentinel, and Pet-Care projects may use it directly. Reaction Game and Scorekeeper makers can instead build a moving winner flag, score marker, or “armed” sign. The key skill is the same for every path: test a mechanism separately before you connect it to the rest of the invention.

Parent guide

What to prepare in advance

• Bring out the Uno, breadboard, button, LED, 220 Ω resistor, piezo, jumper wires, USB cable, and maker notebook. Keep remaining kit parts visible so the child can choose from a real inventory.
• Confirm the Uno still uploads a simple sketch. Open the Components guide, Debugging Ladder, and Arduino IDE.
• Read the capstone choices once yourself. Your job is to check time, safety, and available parts—not to preselect the most impressive project.
• Invite a potential first customer for the final 10 minutes if possible.

Where the child should work independently

Let the child choose the theme, name the user, write the first must-have rule, list inputs and outputs, make the “later” list, sketch pseudocode, wire the proof circuit, and propose the required improvement. He should take ownership of the notebook and decide what evidence will count as success.

Moments when the parent should resist taking over

Do not choose the capstone based on what you would enjoy building. Do not improve a vague idea by adding features; ask the child to make it smaller. Do not write the pseudocode or tell him the correct requirement change. If he selects an ordinary idea that is clear, testable, and his own, that is a better capstone than an ambitious borrowed idea.

When the parent should step in

Step in if a project is unsafe, requires purchases, includes a real lock or anything that can trap something, has more than two new capabilities, or lacks a testable first subsystem. Step in for 5V/ground uncertainty, a hot component, or an Uno/cable/port failure. If the child has spent 15–20 minutes testing one small problem without new evidence, pause, use the Debugging Ladder, and collect an overhead wiring photo, board model, operating system, selected port, error text, full code, and expected-versus-actual behavior.

A simple understanding-based assessment

Ask the child to point to a sketch and explain: “Who is this for? What are the inputs? What rule does the Arduino follow? What outputs tell the user something happened? What small test proved the hardest part?” Assess five things equally: sensible scope, a clear rule, a correct input/output map, evidence from a mini-test, and willingness to revise—not fancy drawings or a completed final gadget.

Further resource: Arduino: What Is Arduino?