Capstone Design Challenges and Course Wrap-Up¶

Summary¶

This capstone chapter ties the whole book together. It introduces the engineering design process -- requirements gathering, prototyping and iteration, user testing, and peer code review -- and shows how to plan a cross-tier project that combines components from at least two hardware families, such as a Pico sensor node feeding data to a Pi 5 running real-time recognition. It covers how to document and present finished work (READMEs, technical documentation, project reflections, portfolios) and how to run a showcase event, whether a science-fair format, a Robot Day-style event, or a community demo day, along with open-ended and constraint-based design challenges that invite original invention. It closes with guidance on where to go next -- the companion books in the series and independent-study extensions -- and a course wrap-up reflection. Students finishing this chapter will be able to design, build, document, and present an original capstone project that spans multiple hardware tiers.

Concepts Covered¶

This chapter covers the following 29 concepts from the learning graph:

Student Portfolio
Capstone Project
Design Brief
Cross Tier Integration
Sensor To Cloud Pipeline
Multi Board Communication
Project Planning Document
Engineering Design Process
Requirements Gathering
Prototype Iteration
User Testing
Peer Code Review
Project Demo Day
Presentation Skills
Technical Documentation
README File
Project Reflection
Science Fair Format
Robot Day Showcase Format
Portfolio Artifact
Open Ended Problem
Constraint Based Design
Original Invention
Remix And Extend
Companion Book Cross Reference
Next Steps Learning Path
Independent Study Extension
Community Showcase Event
Course Wrap Up Reflection

Prerequisites¶

This chapter builds on concepts from:

The Final Build

Berry waving welcome Nineteen chapters of superpowers, and now it's time to combine them into something that's genuinely yours. No pre-written project list this time — just a process for turning your own idea into a real, working, documented build. Let's build something!

Every project earlier in this book started from a lesson plan someone else had already worked out: wire this, code that, test the result. A capstone project starts from a blank page instead, and this chapter is the process that keeps a blank page from turning into a stalled one. It walks through planning an original project, building it in a structured way, documenting it so someone else could understand it, and showing it off — closing with where to go next once this course itself is finished.

The Engineering Design Process¶

The engineering design process is a repeating cycle of defining a problem, designing a possible solution, building and testing it, and refining it based on what that testing reveals — the same iterative spirit as Chapter 1's iterative design, scaled up from a single bug fix to an entire project. Unlike a linear recipe, the process expects to loop back on itself: testing routinely sends a builder back to redesign, not straight to "finished."

Before a single wire gets placed, that cycle starts with understanding the problem clearly. Requirements gathering is the step of figuring out exactly what a project needs to do, for whom, and under what constraints — what sensors does it need, how fast does it need to react, what's the budget — before any design decisions get locked in. The result of requirements gathering is usually written down as a design brief: a short document stating the project's goal, its intended user, its key requirements, and its constraints, written before construction begins so the whole team (even a team of one) is building toward the same target.

Requirements and a design brief describe what to build; a project planning document describes how and when. It breaks the project into a sequence of concrete tasks — order parts, build a first prototype, test the sensor, write the README — each with a rough time estimate, so a capstone with a real deadline doesn't run out of time on the documentation step because every hour went into wiring.

Berry's Key Insight

Berry thinking The engineering design process isn't a straight line from idea to finished project — it's a loop, the same way debugging in Chapter 1 was a loop. Expect to circle back through "design" more than once. That's not falling behind schedule; that's the process working exactly as intended.

Before looking at that loop as a diagram, it helps to know that every stage just defined — requirements gathering, the design brief, and the planning document — maps onto one specific point in the cycle below.

Diagram: Engineering Design Process Loop¶

Run the Engineering Design Process Loop MicroSim fullscreen

Engineering Design Process Loop (clickable diagram)

Type: mermaid-diagram sim-id: engineering-design-process-loop
Library: Mermaid
Template: https://github.com/dmccreary/learning-micropython/tree/main/docs/sims/project-design-process
Status: Specified

Learning objective: Students will apply (Bloom L3: Apply) the stages of the engineering design process to plan their own capstone project, recognizing which stage a given planning activity belongs to.

Canvas: responsive Mermaid flowchart rendered at container width using Mermaid's default responsive SVG scaling.

Layout: a circular Mermaid flowchart (drawn as a flowchart LR looping back on itself) with five stages: "Gather Requirements" → "Write a Design Brief" → "Plan the Project" → "Build a Prototype" → "Test with Real Users" → an arrow looping back to "Gather Requirements," with a secondary short-loop arrow from "Test with Real Users" directly back to "Build a Prototype," showing that testing more often sends a builder back to rebuilding than all the way back to requirements.

Interaction: every node has a click directive that opens an infobox beneath the diagram containing that stage's one-sentence definition, matched to the surrounding chapter prose, plus one example task from a Pico-sensor-to-Pi-5 capstone (e.g., clicking "Build a Prototype" shows "Example: wire the Pico sensor node and confirm it reads correctly before adding wireless communication"). Only one infobox is open at a time.

Implementation: Mermaid flowchart LR syntax with a click NodeId "javascript:showInfobox('NodeId')" directive on every node, paired with a small JavaScript object mapping node IDs to definition and example text.

Prototyping, Testing, and Feedback¶

A design brief describes an intention; a prototype iteration turns that intention into an early, incomplete, working version built specifically to test one idea, then rebuilds it again based on what was learned — the same prototype concept from Chapter 1, now used repeatedly across a whole project rather than once. Most capstones go through several prototype iterations before anything is considered finished, and each iteration is expected to be rougher than the last one was polished.

A prototype only teaches a builder something once someone tries to actually use it. User testing is the practice of putting a prototype in front of a real person — ideally someone who wasn't the one who built it — and observing how they interact with it, rather than asking them to imagine how they'd use it. A robot that makes perfect sense to its builder can baffle a first-time user within seconds, and that gap is exactly what user testing exists to surface early.

Code benefits from the same kind of outside eyes. Peer code review is the practice of having another student read through a project's code before it's considered finished, checking for bugs, unclear logic, or missing error handling that the original author has stopped noticing simply from having stared at it too long. It's rubber duck debugging from Chapter 1, upgraded from an inanimate duck to a classmate who can actually answer back.

Berry's Tip

Berry sharing a tip When you ask a classmate for a peer code review, ask a specific question instead of a general one. "Does this work?" gets a shrug. "Can you follow why I check the distance sensor twice in this function?" gets you an actual answer — and often finds the bug faster than either of you expected.

What Is a Capstone Project?¶

A capstone project is a self-directed, original build completed at the end of a course of study that demonstrates a student's ability to combine multiple skills learned throughout that course into one working result, rather than practicing a single new skill in isolation. In this book, that almost always means cross-tier integration: combining components from at least two of the five hardware tiers covered earlier — a Pico sensor node feeding data to a Pi 5 running real-time recognition, for example — since no single tier's toolkit demonstrates the full range of what the course covered.

Cross-tier integration usually requires two boards to talk to each other, which is multi-board communication: any method by which one microcontroller or computer sends data to, or receives data from, another board, typically over Wi-Fi (using the Pico W skills from Chapter 10) or a wired serial connection. When that communication carries sensor readings from a low-power board up to a more capable one for processing or storage, the specific pattern has its own name: a sensor-to-cloud pipeline — a chain in which a sensor node captures a reading, transmits it (locally to a Pi 5, or further out to an internet service), and a more powerful system further down the chain processes, stores, or acts on it.

Berry's Key Insight

Berry thinking A cross-tier capstone is the sense-think-act cycle from Chapter 1, just stretched across two boards instead of squeezed onto one. The Pico still senses; it just hands the "think" step to a Pi 5 with far more processing power, then waits for an "act" instruction to come back.

Before the diagram below, note that the sensor-to-cloud pipeline just defined is really one specific path through a larger multi-board architecture — the next diagram lets you trace that whole path, click by click.

Diagram: Cross-Tier Capstone Architecture¶

Run the Cross-Tier Capstone Architecture MicroSim fullscreen

Cross-Tier Capstone Architecture (graph data model)

Type: graph-data-model sim-id: cross-tier-capstone-architecture
Library: vis-network
Status: Specified

Learning objective: Students will analyze (Bloom L4: Analyze) how components across two hardware tiers communicate in a cross-tier capstone project, tracing a reading from sensor to final action.

Canvas: 700x400px, responsive via vis-network's autoResize option combined with a window resize listener calling network.redraw().

Layout: a left-to-right vis-network graph with four nodes: "Pico Sensor Node" (Tier 1/2 style, indigo #3F51B5), "Wi-Fi Link (Pico W)" (raspberry #C2185B), "Raspberry Pi 5" (circuit green #2E7D32), "Action / Output" (copper gold #D4AF37), connected by directional edges labeled "sensor reading" (node 1 to 2), "data over Wi-Fi" (node 2 to 3), "decision" (node 3 to 4).

Controls: a createSelect()-equivalent HTML dropdown labeled "Example Project," with two preset options — "Distance sensor to smart alert" and "Sound classifier to NeoPixel signal" — that swap the edge labels and node subtitles to match a concrete example from earlier chapters.

Interaction: clicking any node opens an infobox describing that stage's role in the current example project, plus which earlier chapter introduced the underlying hardware or concept (e.g., clicking "Raspberry Pi 5" references Chapter 16's AI HAT+ inference). Hovering an edge shows its data-type label as a tooltip.

Implementation: vis-network hierarchical left-right layout, node and edge label text swapped via a small JavaScript object keyed by the dropdown's selected example, using network.setData() to redraw when the example changes.

Choosing a Challenge: Open-Ended, Constrained, or Remixed¶

Not every capstone starts from the same kind of prompt, and it helps to know which kind fits a given idea. An open-ended problem states a goal without specifying how to reach it — "build something that helps someone in your daily life" — leaving the approach, the hardware, and even the exact interpretation of the goal entirely up to the builder. Constraint-based design takes the opposite approach: a specific goal paired with firm limits, such as a fixed budget, a required sensor, or a maximum size, that force creative problem-solving within a defined box rather than an unlimited one.

A capstone doesn't have to be a brand-new idea to count as real engineering work. An original invention is a project whose combination of purpose, hardware, and behavior hasn't appeared anywhere else in this book, even if every individual piece it's built from has. Remix and extend describes the alternative path: taking a project from an earlier chapter and deliberately changing or adding to it — a new sensor, a new behavior, a new use case — which is just as legitimate a capstone as an original invention, since remixing still requires understanding a project well enough to meaningfully change it.

You've Got This!

Berry encouraging you There's no wrong door into a capstone. An open-ended idea that scares you a little is a good sign, not a red flag — and remixing a project from Chapter 5 or Chapter 8 into something new is exactly as impressive as inventing from scratch. Pick the door that gets you building sooner rather than the one that sounds most impressive on paper.

Diagram: Capstone Challenge Type Picker¶

Run the Capstone Challenge Type Picker MicroSim fullscreen

Capstone Challenge Type Picker (interactive infographic)

Type: interactive-infographic sim-id: capstone-challenge-type-picker
Library: p5.js
Status: Specified

Learning objective: Students will evaluate (Bloom L5: Evaluate) which capstone challenge type — open-ended, constraint-based, original invention, or remix and extend — best fits their own project idea.

Canvas: 700x420px default, responsive — recompute card positions from windowWidth in windowResized(), switching from a 2x2 grid to a stacked 4x1 layout below 500px wide.

Layout: four cards, one per challenge type, each showing its name and a one-line description drawn from the surrounding chapter prose. A short three-question quiz panel sits below the cards: "Do you already have a project idea in mind?", "Do you want firm constraints (budget, size, required part) or full freedom?", "Are you starting from scratch or building on an earlier chapter's project?"

Controls: three createRadio() groups, one per quiz question, each with two or three simple answer options; a createButton() labeled "Suggest a Challenge Type."

Interaction: clicking "Suggest a Challenge Type" highlights the one card (of the four) that best matches the combination of radio answers, using a simple rule table mapping answer combinations to a recommended type, and displays a one-sentence rationale beneath the highlighted card. Clicking any card directly (without using the quiz) also highlights it and shows its full description, letting a student explore all four options freely.

Implementation: p5.js with createRadio() and createButton() p5.js DOM controls, a small lookup table mapping the three radio answers to one of the four challenge-type cards, redrawn each frame to reflect the currently highlighted card.

Documenting the Work¶

A finished capstone that nobody but its builder can understand is only half finished. Technical documentation is written material that explains how a project works, how to set it up, and how to use it, aimed at a reader who wasn't there while it was built. The most common piece of technical documentation for a software or hardware project is a README file: a single document, conventionally named README.md, placed alongside a project's code, that a new reader opens first to learn what the project does, what hardware it needs, and how to run it.

Documentation isn't only about explaining the finished result — it's also a place to think honestly about the process. A project reflection is a short piece of writing, completed after a capstone is finished, describing what worked, what didn't, what the builder would change with more time, and what they learned that they didn't know at the start — turning a finished build into a genuine record of learning, not just a working device.

Before showing what a README actually looks like, it helps to know its typical sections match the questions a new reader asks in order: what is this, what do I need, and how do I run it.

# Smart Plant Alert

A Pico sensor node that measures soil moisture and sends an alert
to a Raspberry Pi 5, which lights a NeoPixel red when a plant needs water.

## Hardware Needed
- Raspberry Pi Pico W
- Soil moisture sensor
- Raspberry Pi 5
- NeoPixel LED

## Setup
1. Flash `sensor_node.py` to the Pico W.
2. Run `pi5_listener.py` on the Pi 5.
3. Power both boards; the NeoPixel turns red below 30% moisture.

## What I'd Change Next
Add a second sensor to compare readings across two plants.

The ## What I'd Change Next section above is a project reflection folded directly into the README, showing that documentation and reflection don't have to live in separate files.

Building a Student Portfolio¶

A single capstone tells the story of one project; a student portfolio collects evidence of a student's work and growth across an entire course, giving a fuller picture than any single project could on its own. A portfolio is built from portfolio artifacts: individual pieces of evidence — photos of a working build, a code snippet, a short demo video, a project reflection — each one chosen because it demonstrates a specific skill or milestone, not simply everything a student happened to produce.

Berry's Serious Warning

Berry warning Before posting any portfolio artifact publicly — a demo video, a photo from a showcase, a project writeup with a student's name attached — check your program's policy on sharing student work online, and get explicit permission from the student (and a parent or guardian, if the student is a minor). A great project deserves to be shown off the right way, not just the fast way.

Presenting and Showcasing the Finished Project¶

Documentation explains a project to a reader; presentation skills are what it takes to explain a project to a live audience — a clear, concise description of what the project does, why it was built that way, and a confident answer to "what would you do differently," delivered in the few minutes a showcase visitor is likely to give any one project. Those skills get exercised at a project demo day: a scheduled event, in class or beyond it, where every student demonstrates their finished capstone to an audience.

A demo day can take more than one shape depending on a program's goals and resources. A science fair format presents projects at individual stations with a poster or display board, judged against a rubric, in the tradition of a classic science fair. A Robot Day showcase format — named for the companion book Robot Day — centers on live, hands-on demonstrations of working robots and physical builds rather than static posters, prioritizing interaction over explanation. A community showcase event opens the demo day beyond the classroom to parents, other classes, or the public, turning a class assignment into a genuine public presentation.

Now that all three formats are defined, the table below compares them across what matters most when choosing one for a given class.

Format	Best Fit	Audience	Emphasis
Science fair format	Research-heavy or data-driven capstones	Judges, peers	Explanation and rigor
Robot Day showcase format	Physical, interactive builds	Peers, younger students	Live demonstration
Community showcase event	Any polished capstone ready for a public audience	Parents, community, public	Presentation and outreach

Berry's Tip

Berry sharing a tip Whichever format you choose, practice your explanation on someone who's never seen the project before you present it for real. If they get confused, that's not a them problem — that's exactly the gap your actual audience will hit too.

Diagram: Showcase Format Comparison¶

Run the Showcase Format Comparison MicroSim fullscreen

Showcase Format Comparison (interactive infographic)

Type: interactive-infographic sim-id: showcase-format-comparison
Library: Chart.js
Status: Specified

Learning objective: Students will evaluate (Bloom L5: Evaluate) which showcase format best fits a given capstone project and its intended audience.

Canvas: 700x420px, responsive via Chart.js responsive: true and maintainAspectRatio: false inside a fixed-height wrapper.

Data: a radar (spider) chart with three overlapping series, one per showcase format from the table above, each scored 1-5 across four axes: "Live Demonstration," "Formal Judging," "Public Reach," "Preparation Time Needed." Series colored using the book's accent palette.

Controls: three checkboxes, one per format, allowing a student to toggle any series on or off to compare formats one at a time or all together.

Interaction: clicking a data point on any axis opens a small tooltip (Chart.js's built-in tooltip plugin) explaining, in one sentence, why that format scores the way it does on that axis, pulled from the surrounding chapter prose. A short text panel below the chart updates to recommend a format when only one checkbox is active, based on which axes score highest.

Implementation: Chart.js radar chart type with a plugins.tooltip.callbacks.label function supplying the custom one-sentence explanations, and checkbox onchange handlers toggling dataset visibility via chart.getDatasetMeta(index).hidden.

First Milestone Unlocked!

Berry celebrating Planned, built, documented, and shown to a real audience — that's a complete project, start to finish. Whatever you build for your capstone, reaching this point is worth celebrating on its own, before we even get to what comes next.

Where to Go Next¶

This course was deliberately built wide rather than deep, surveying five hardware tiers instead of mastering just one. Several companion book cross references point to where that depth actually lives: Moving Rainbow for the full NeoPixel animation library, STEM Robots for full-semester robot construction and swarm behaviors, Clocks and Watches for the complete display-driver catalog, Robot Faces for deep OLED expression programming, and AI Racing League for autonomous vehicle machine learning pipelines.

Which companion book fits best depends on which chapter of this course felt most exciting, and that choice is really a next steps learning path: a personalized sequence of what to study after this course, based on a student's own interests rather than a single fixed order every reader is expected to follow. For a student who wants to go deeper without necessarily picking up an entire companion book, an independent study extension is a smaller, self-directed follow-up project — extending a capstone with one new feature, or rebuilding it on a different hardware tier — that doesn't require a new course to get started.

Diagram: Your Next Steps Learning Path¶

Run Your Next Steps Learning Path MicroSim fullscreen

Your Next Steps Learning Path (graph data model)

Type: graph-data-model sim-id: next-steps-learning-path
Library: vis-network
Status: Specified

Learning objective: Students will evaluate (Bloom L5: Evaluate) which companion book or independent study extension best matches their own interests after completing this course.

Canvas: 700x450px, responsive via vis-network's autoResize option and a window resize listener calling network.redraw().

Layout: a central node labeled "Learning STEM with Raspberry Pi Hardware (this course)" connected to five surrounding nodes, one per companion book — "Moving Rainbow," "STEM Robots," "Clocks and Watches," "Robot Faces," "AI Racing League" — plus a sixth node labeled "Independent Study Extension" for students not ready to commit to a full companion book yet.

Controls: a createSelect()-equivalent HTML dropdown labeled "Your Favorite Chapter," listing five representative chapters (e.g., "NeoPixel LED Art," "STEM Robot Building," "Clocks and Watches," "RGB Keyboard Lighting," "Real-Time Image Recognition") that, when selected, highlights the single best-matching companion book node with a glowing border.

Interaction: clicking any companion-book node opens an infobox with a one-sentence description of what that book covers in depth, matching the "Topics Not Covered" list from this course's description. Clicking "Independent Study Extension" opens an infobox with three example self-directed extension ideas, drawn from earlier capstone examples in this chapter.

Implementation: vis-network star-shaped layout with the course node fixed at the center, network.selectNodes() used to apply the highlight style when the dropdown changes, and a small JavaScript lookup object mapping dropdown choices to node IDs.

Course Wrap-Up Reflection¶

Just as a single capstone benefits from a project reflection, finishing an entire course benefits from a course wrap-up reflection: a short piece of writing looking back across every chapter completed, naming which hardware tier felt most natural, which bug took the longest to solve, and which skill feels like it's actually become a habit rather than something looked up each time. Where a project reflection looks back at one build, a course wrap-up reflection looks back at the whole journey — decomposition, pattern recognition, abstraction, and algorithm design, first named all the way back in Chapter 1, applied over and over across breadboards, robots, keyboards, cameras, and microphones.

Bringing It Together¶

This chapter, and this book, end the same place they started: a $4 Pico, a breadboard, and the four pillars of computational thinking from Chapter 1. Everything between that first chapter and this one — NeoPixels, robots, clocks, a keyboard computer, real-time vision, real-time sound — was the same sense-think-act cycle, wearing different hardware. A capstone project is proof that the cycle is now yours to point at a problem nobody assigned you, using whichever tier, or combination of tiers, actually fits what you're trying to build.

STEM Is Our Superpower — Every Chapter of It

Berry celebrating That's berry impressive — not just this chapter, all twenty of them. You started with computational thinking and a breadboard, and you're finishing with the judgment to design, build, document, and show off an original project on hardware you chose yourself. Every wire told a story, every bug was data, and every superpower here is one you earned, not one you were handed. STEM is our superpower — now go build something the rest of us haven't seen yet. Thanks for building with me!

See Annotated References