Smart Waste Collection Point

Picture a smart waste point on your Learning Group's city tile. Citizens need to know when a bin is full, a lid should open for deposit, and status lights plus a display should make fill level obvious. Optionally a second stream (general vs recycling) doubles the work across two sprints. That is embedded logic: distance sensing drives lid, alerts, and status outputs together.

In this challenge you design and build a smart waste collection point for your Learning Group city tile: measure fill level, control a lid, and show status with RGB/LEDs, OLED, and a full buzzer. Because this challenge spans two sprints, the delivered result is a multi-side or multi-stream system — not a single ultrasonic blink. You integrate into the city’s shared firmware, make sensor data and controls available to full-stack classmates, and work through research, advice, design, and realisation for your Sprint 1-2 Learning Goal. Follow the city Requirements.

Your Learning Goal title in Portflow

Use: Sprint 1-2 - Learning Goal - Smart Waste Collection Point (adjust the sprint number if needed). See the Learning Goal page for the Portflow template.

Illustration

The animation below shows the idea in simplified form (fill level rising, lid, status colour). Your delivered system should prefer two streams (e.g. general + recycling) or otherwise enough depth for two sprints — fill sensing, lid, status outputs, and full alert.

Challenge

Your Learning Group city needs a smart waste collection point on a city tile. An ultrasonic (or similar) measures fill level; a servo lid opens for deposit; RGB/LEDs and OLED show status; a buzzer alerts when full. Prefer two streams (general vs recycling) for multi-side scope across two sprints. Your work is part of one shared embedded firmware for the city — not a separate personal project.

You will deliver a working prototype and the documents that justify and explain it. Work in this order:

Understand the problem. One bin or two streams? How is fill level mapped to empty / warning / full? When may the lid open? When does the buzzer run? Write clear rules. Agree which tile template you use and how this challenge fits the city plan.
Research. Compare realistic ways to measure fill level, drive a lid servo, and show status (LEDs/OLED/buzzer), plus how to handle two streams if you build them. Include how you will expose fill data and controls to the full-stack side. Use datasheets and cite resources for decisions.
Advise. Recommend one architecture: microcontroller role in the shared city firmware, sensors and outputs per stream, and the data/control interface for full-stack. State what you are not building in this period.
Design. Specify hardware (wiring, pin map, BOM) and software (state machine for fill states, lid timing, interface messages) so someone else could rebuild your system and integrate it into the shared firmware.
Realise. Build and test in small steps. Prefer separate Arduino sketches for parts (ultrasonic, servo lid, RGB/OLED, buzzer, then second stream) before you merge working pieces into the shared city firmware on GitLab main. Keep each test sketch tiny. Then demonstrate: fill level drives status, lid, and full alert — on at least one stream, preferably two. Use simulation or stubs if full-stack or other tiles are not ready yet — do not wait on classmates to progress.

Minimum scope (Sprint 1–2)

Your contribution must include:

Ownership of one city tile based on a LightBurn template, with the waste point placed on that tile (or a clear bench stand-in while the tile is cut).
Integration into the city’s one shared embedded firmware (follow the city’s code conventions; do not ship a parallel personal firmware stack).
A microcontroller (e.g. ESP32-class board) that runs that shared firmware with your waste-point behaviour included.
For at least one stream (preferably two — general and recycling — for full two-sprint depth):
- An ultrasonic fill-level sensor (HC-SR04) aimed into the bin stand-in,
- A servo lid (SG90) that opens on request/button and closes after timeout (or stays locked when full — document your rule),
- Status outputs: RGB or discrete LEDs for empty/warning/full, plus OLED text/level, and a buzzer when full.
If you build only one physical bin in Sprint 1, Sprint 2 must add either a second stream or equivalent multi-side depth (second sensor path, dual status, coordinated lids) — document the choice so the result is clearly more than a single-sensor demo.
Firmware that maps distance to fill states and coordinates lid + alerts. Example pattern:
- Empty/normal: green status, lid may open,
- Warning: yellow status,
- Full: red status, buzzer, lid stays closed (or opens only for emptying mode you document).
A documented threshold table (distance → state) and lid timing. Keep it simple and explain your choice.
Filtering on ultrasonic readings and timeouts so the lid and buzzer cannot chatter.
A documented data and control interface for full-stack developers: fill level/state per stream, lid state, plus commands that can request lid open or acknowledge full (message names, payload fields, and an example). Full-stack may connect later — you still define and demo the interface (Serial, MQTT, or another city-agreed protocol), with simulation if needed.
Updates to the city’s shared BOM and wiring diagram for your hardware.

Recommended scope

If you have time, add one or more of:

A clear second bin stream (recycling) with its own sensor, lid, and status.
Serial debug output showing raw distance and mapped fill %.
A simple bin model (cardboard) so fill simulation is obvious in demos.
A potentiometer as a demo stand-in to force fill level during presentations.
A stub or simulator feed that full-stack can use before your hardware is on the desk.

Out of scope for this challenge

These are not part of this challenge:

Real municipal routing optimisation or truck dispatch algorithms.
Computer vision / ML waste sorting.
Production PCB fabrication or outdoor weatherproof enclosures as a hard requirement.
Building the city back-end, front-end, or Raspberry Pi stack yourself — that is full-stack work. You do define and expose the embedded interface they connect to.
A separate personal firmware repo that never merges into the city’s shared embedded application.

Demo and safety context

Treat the prototype as lab equipment, not street furniture:

Default lid closed when full or unsure; never leave the buzzer screaming without a documented silence/reset path.
Predictable rules. Document exactly when each fill state changes and when the lid may open.
Clear demo script. Anyone in your Learning Group can show at least: empty → green; rising fill → warning; full → red + buzzer + lid policy; lid open/close on request when not full.
Independent progress. You can demo your tile and interface with simulation or stubs while classmates finish their parts.

Starting points

Use these concrete first steps early in Sprint 1:

Read the city Requirements and agree your challenge with the Learning Group (no duplicate challenges).
Pick your tile template and sketch bin(s), lid, sensor, and status placement.
Agree on fill and lid rules. Distance thresholds and when the lid locks. Write rules in plain language.
Inventory hardware. List what your studio kit provides (ESP32, HC-SR04, SG90, OLED, RGB/LEDs, buzzer, breadboard). Note gaps early and ask your coach. Start the city’s shared BOM. Optional KY modules from coach stock are fine if documented.
Test in small sketches first. Create short Arduino sketches for one concern at a time (e.g. ultrasonic distance, servo lid, OLED text, RGB states, buzzer, then second stream). Do not develop everything only inside the city’s main shared firmware.
Blink one LED to confirm toolchain: IDE, upload, Serial.begin, one GPIO. See First ESP32 project.
Draft the full-stack interface with your city (per-stream fill messages and lid override). Agree a simulation path so neither side waits. Prove the messages in a small sketch before wiring them into shared firmware.
Draft your research question. Example: Which fill sensor, lid actuator, and status outputs best fit a multi-stream waste point given false readings, GPIO limits, and full-stack integration?
Create your Learning Goal in Portflow. Link the product deliverables you plan to submit. Follow Learning Goal.
Integrate only what works. Prove one stream in sketches, then status + lid, then second stream or coordination; move proven behaviour into the shared firmware in small merges.

Suggested sprint timeline

The Learning Group does not use Scrum, but you still follow the sprint rhythm of the Group Project: two sprints for this challenge (Sprint 1-2).

In the first sprint you focus on research and advice (including multi-stream if planned) and prove one subsystem (e.g. ultrasonic → status) in small sketches. In the second sprint you focus on design and realisation of the full system: lid, alerts, second stream/depth, shared-firmware integration, and the full-stack interface.

Sprint	Focus	Outcome
1	Research & advise (+ first subsystem in sketches)	Research report; advisory report; tile and streams chosen; fill/lid rules; hardware choice; draft data/control interface; one subsystem proven in a small test sketch
2	Design & realisation (multi-stream / full point)	Wiring diagram + pin map + fill-state diagram; shared BOM updated; fill + lid + status + buzzer (and preferably two streams) in shared firmware on city GitLab `main`; demo (with simulation if needed); Portflow evidence linked; reflection

Tools, frameworks, and hardware

Area	Suggestions
City tile	One of the five LightBurn templates
Microcontroller	ESP32 / ESP32-S3 / ESP32-C3 (align with city hardware choices)
Actuators	SG90 servo (lid); RGB/LEDs; buzzer; optional WS2812 status strip
Display	OLED for fill % / stream label
Sensors	Ultrasonic HC-SR04 per stream; button for lid request; optional potentiometer demo stand-in
IDE	Arduino IDE or PlatformIO
Version control	City GitLab project, shared firmware on `main`
Documentation	Markdown on the city MkDocs site and in the repo (English); cite sources for decisions
Full-stack link	Documented messages (Serial, MQTT, or city-agreed protocol); stubs/simulation so you do not block each other

Profile knowledge worth revisiting:

Products

Your challenge evidence is a set of products: studio deliverables tied to learning outcomes. Submit them in Portflow and link them from your Learning Goal.

Analyse & Advise

Product	What you deliver	Template
Research	Analysis of fill-level sensing, lid control, and status/alert outputs (including multi-stream options); comparison with criteria; recommendation for design	Research product
Advice	Decision document: chosen MCU role in shared firmware, sensors and outputs per stream, fill thresholds, full-stack data/control interface, and implementation order (one stream → lid/status → second stream)	Advisory report

Suggested titles for Portflow

Research: Fill-level sensing for smart waste collection point
Advice: Multi-stream waste point lid and status architecture

The advice report should build on the research report. Do not repeat the full comparison tables.

Design & Realise

Product pages for design and realisation are still being added to the studio catalogue. For this challenge, deliver the following and attach them as evidence (repository links, PDFs, or videos as your coach specifies).

Product	Learning outcome	What you deliver
System design	Design & Realise	Self-contained design document: context, city requirements link-in, block diagram for stream(s), circuit/wiring diagram, pin assignment table, fill state machine (diagram + description), timing parameters, software module overview for the shared firmware, per-stream data/control interface for full-stack, contribution to the city BOM, and test plan
Prototype realisation	Design & Realise	Working prototype on your city tile (or documented bench stand-in), code integrated in the city’s shared firmware on GitLab `main`, README with build/upload steps, interface demo (live or simulated), and validation evidence showing fill states, lid, and full alert

Suggested titles for Portflow

Design: Smart Waste Collection Point — hardware and firmware specification
Realisation: Smart Waste Collection Point — prototype and validation

System design — minimum contents

Your design document should let a peer rebuild and integrate the system without guessing:

Requirements. Rules for empty / warning / full, lid policy, and (if used) per-stream behaviour; how this fits the city Requirements.
Architecture diagram. MCU, ultrasonic(s), lid servo(s), RGB/OLED/buzzer, power, and the path to full-stack (protocol boundary).
State machine. States that cover normal, warning, full, lid open, and optional override/emptying mode.
Timing table. Lid open duration; ultrasonic sample rate; buzzer pattern when full.
Pin map and wiring diagram. GPIO ↔ component for every stream; include resistor values for LEDs.
BOM. Parts list aligned with the city’s shared BOM.
Sensor handling. Threshold, filter/average, and timeout logic per stream.
Full-stack interface. Messages for fill level/state per stream, plus lid controls; example payloads; how to test with a stub or simulator.
Shared firmware. Where your modules live in the city codebase and which code conventions you follow.
Test plan. e.g. “empty → green”, “warning”, “full → red + buzzer”, “lid open when not full”, “lid locked when full”, “second stream if present”.

Realisation — minimum evidence

Small test sketches (or a short test log) showing you verified parts separately: ultrasonic, lid, OLED, RGB, buzzer, then coordination — before integration.
Work on the city GitLab project: proven behaviour merged (or ready to merge) into main as part of the shared firmware — not a dump of unfinished experiments into main.
Photo or diagram of the physical build on the tile (or bench stand-in with a clear path to the tile), with streams labelled.
Demo script (numbered steps) matching your video or live assessment, covering fill states, lid, alerts, and the data/control interface.
Proof you can progress without waiting on full-stack (simulation, Serial demo, or stub consumer).
Honest known limitations (e.g. ultrasonic noise, interface not yet wired to the Pi).

Quality indicators

When assessing this challenge as a whole, the following indicators are used. Use them as a self-check before you submit.

Problem fit

The fill states and lid / alert rules (and streams if used) are described in plain language.
Scope is explicit: this challenge delivers a waste point with fill sensing, lid, status, and full alert (preferably multi-stream) on your city tile, integrated into shared firmware — not a single-sensor demo or a solo firmware fork.
The work respects the city Requirements (tile, shared firmware, BOM/wiring, full-stack interface, no waiting on classmates).

Analyse & Advise products

Research and advice reports meet the research and advisory report quality indicators.
The advice report references the research report and states one clear recommended architecture, including how fill data and controls reach full-stack.
Component and approach choices are supported by datasheets or comparable evidence, not only opinion. Decisions cite resources.

Design

The design document is self-contained and includes a fill state machine plus timing rules that match the intended firmware behaviour.
Pin map, wiring diagram, and BOM cover sensors and outputs (per stream if used) and match the realised prototype (or differences are documented with reason).
Fail-safe behaviour is designed explicitly (lid closed when full/unsure, buzzer timeout/silence path).
The data/control interface for full-stack is specified with example messages per stream.

Realisation

The prototype demonstrates fill-level sensing, lid control, status RGB/LEDs + OLED, and buzzer on full.
Behaviour lives in the city’s shared firmware on GitLab main (or is clearly opened as an integration MR), following city code conventions.
Firmware is readable: meaningful names, constants for thresholds/timings, no unexplained magic numbers.
Ultrasonic input is filtered; state changes are observable via Serial log or demo script.
The full-stack interface is demonstrable (live or with simulation/stubs) without depending on a finished back-end.
Validation evidence covers normal, warning, full, lid, and at least one edge case (e.g. noisy reading, override).
Repository README explains how to build, flash, and run the demo as part of the city project.

Professional practice

Learning Goal in Portflow uses the correct naming format and links to all product evidence.
End-of-sprint reflection connects results to your learning question and to embedded practice (timing, I/O, thresholds, city integration).
Documentation is in English Markdown and usable by other city students on their tiles.
You did not block on classmates: simulation, stubs, or a local demo kept you moving.

Focus points

Watch out for these common issues while you work:

Stopping at raw distance. Two sprints mean states + lid + status + alert (and preferably two streams).
Lid vs full mismatch. Never open freely when full unless you document an emptying mode.
Everything in main firmware. Develop and test parts in small Arduino sketches first; only integrate working pieces into the shared city firmware.
Solo firmware forever. Test sketches are fine for learning; the assessed integration still joins the shared city firmware per the Requirements.
Waiting on full-stack. Define the interface early and demo with Serial/stubs; do not pause realisation until the Pi dashboard exists.
Blocking delay() everywhere. Long delay() calls miss fill changes. Prefer millis()-based state machines or timers.
Ultrasonic noise. Average readings; document sensor aim inside the bin stand-in.
Servo power. Do not starve the MCU; power the lid servo appropriately and document it.
Advice without analysis. Coaches will send back an advice report that invents new comparisons not present in research.
Design–code drift. Update the design document when you change pins, thresholds, timings, or interface messages during realisation.

Key points

Core task: measure fill level → update status, lid, and full alert on your city tile.
Because this is Sprint 1-2, prefer a multi-stream result (or equivalent depth), not a single-sensor sketch.
Test small parts in separate Arduino sketches; integrate only what works into one shared firmware.
Expose per-stream data and controls for full-stack; keep a shared BOM and wiring diagram.
Deliver four products: research, advice, system design, and prototype realisation.
Work research → advice → design → realise; Sprint 1 emphasises research & advice (and proving one subsystem); Sprint 2 emphasises full-point design & realisation.
Municipal routing / CV sorting are out of scope; building the city back-end/front-end is out of scope for you.
Link everything to your Learning Goal in Portflow and reflect at the end of Sprint 1-2.