Adaptive Park Lighting

Picture a park path on your Learning Group's city tile. Lights should dim with ambient daylight and brighten when someone is present, with clear scenes on a WS2812 strip and a small status display. Two light zones or poles give enough depth for two sprints. That is embedded logic: LDR and PIR inputs drive coordinated lighting outputs in real time.

In this challenge you design and build adaptive park lighting for your Learning Group city tile: dim from outside light, brighten on presence, show strip scenes, and run at least two light zones/poles. Because this challenge spans two sprints, the delivered result is a multi-zone system — not a single LED with one LDR. 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 - Adaptive Park Lighting (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 (ambient dimming, presence brightening on a path). Your delivered system must cover at least two light zones/poles — each responding with clear rules.

Challenge

Your Learning Group city needs adaptive park lighting on a city tile. An LDR sets ambient dimming; a PIR (or similar) brightens when someone is present; a WS2812 strip provides scenes; an OLED shows status. You control at least two zones/poles. 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. Which two zones/poles do you control? How does LDR map to base brightness? How long does presence keep a zone bright? What strip scenes exist (idle vs presence)? Write clear rules. Agree which tile template you use and how this challenge fits the city plan.
Research. Compare realistic ways to read ambient light, detect presence, and drive multi-zone WS2812 / LED lighting, plus how to keep zones independent but consistent. Include how you will expose light 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, outputs per zone, 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 multiple zones, thresholds, 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 (LDR → brightness, PIR, one WS2812 zone, OLED, then second zone) before you merge working pieces into the shared city firmware on GitLab main. Keep each test sketch tiny. Then demonstrate: both zones dim with ambient light and brighten on presence without fighting each other. 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 park lighting 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 multi-zone lighting behaviour included.
Control of at least two light zones/poles. Across the system you must include:
- An LDR for ambient dimming (shared or per zone — document your choice),
- Presence sensing (PIR and/or button stand-in) that can brighten zones,
- A WS2812 8-LED strip (or more) used for at least two logical zones or scenes,
- An OLED status (mode, brightness, which zone is active).
Firmware that updates each zone based on ambient + presence. Example pattern:
- Day/high ambient: low or off base level,
- Night/low ambient: dim idle scene on both zones,
- Presence near zone A → zone A bright scene; zone B stays idle unless also triggered,
- After presence timeout → return to ambient-dimmed idle.
A documented brightness / scene table and presence timeout. Keep it simple and explain your choice.
Filtering on LDR/PIR and timeouts so lights cannot flicker endlessly.
A documented data and control interface for full-stack developers: ambient reading, presence per zone, brightness/scene per zone, plus commands that can force a scene or brightness (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 third zone or richer WS2812 scenes (warm path, cool idle).
Serial debug output showing LDR, PIR, and per-zone brightness.
A simple path model (tape, cardboard poles) so zones are obvious in demos.
A sound sensor (KY-037) as an optional second trigger for brightening.
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:

City-wide adaptive lighting networks beyond your tile.
Computer vision / ML pedestrian tracking.
Mains-voltage lamp control or production outdoor luminaires.
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 lighting infrastructure:

Default to a dim/safe idle when sensors are unsure at night; never leave strip power undocumented.
Predictable rules. Document exactly when each zone brightens relative to LDR and presence.
Clear demo script. Anyone in your Learning Group can show at least: cover LDR → dimmer base; trigger presence on zone A → A brightens; zone B independent; timeout returns to idle.
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 two poles/zones, LDR, PIR, strip, and OLED placement.
Agree on multi-zone rules. For each zone: when is it idle vs bright? Write rules in plain language.
Inventory hardware. List what your studio kit provides (ESP32, LDR, PIR, WS2812 strip, OLED, 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. LDR → PWM/brightness, PIR, WS2812 zone A, OLED, then zone B). 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-zone topics/messages and a scene 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 ambient/presence sensors and multi-zone WS2812 approach best fit adaptive park lighting given power, flicker, 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 zone A in sketches, then zone B, then coordination with LDR; 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 the multi-zone concept) and prove one zone in small sketches. In the second sprint you focus on design and realisation of the full multi-zone system: second zone, ambient+presence coordination, shared-firmware integration, and the full-stack interface.

Sprint	Focus	Outcome
1	Research & advise (+ first zone in sketches)	Research report; advisory report; tile and zones chosen; ambient/presence rules; hardware choice; draft per-zone data/control interface; one zone proven in a small test sketch
2	Design & realisation (multi-zone)	Wiring diagram + pin map + multi-zone state diagram; shared BOM updated; at least two zones coordinated in shared firmware on city GitLab `main`; demo of both zones (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 / light	WS2812 8-LED strip (split into zones); optional discrete LEDs
Display	OLED status
Sensors	LDR (ambient); PIR (presence); optional KY-037 sound; potentiometer for demo brightness
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 ambient dimming, presence brightening, and multi-zone strip lighting; comparison with criteria; recommendation for design	Research product
Advice	Decision document: chosen MCU role in shared firmware, sensors and lights per zone, scene rules, full-stack data/control interface, and implementation order (one zone → second zone → coordination)	Advisory report

Suggested titles for Portflow

Research: Ambient and presence sensing for adaptive park lighting
Advice: Multi-zone adaptive park lighting 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 multiple zones, circuit/wiring diagram, pin assignment table, lighting state machine (diagram + description), timing parameters, software module overview for the shared firmware, per-zone data/control interface for full-stack, contribution to the city BOM, and test plan
Prototype realisation	Design & Realise	Working multi-zone 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 coordinated behaviour on different zones

Suggested titles for Portflow

Design: Adaptive Park Lighting — multi-zone hardware and firmware specification
Realisation: Adaptive Park Lighting — multi-zone prototype and validation

System design — minimum contents

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

Requirements. Per-zone rules for idle / presence, and LDR mapping; how this fits the city Requirements.
Architecture diagram. MCU, LDR, PIR, WS2812 zones, OLED, power, and the path to full-stack (protocol boundary).
State machine. States that cover day/off, night idle, presence bright per zone, and optional override scenes.
Timing table. Presence hold time; LDR sample rate; scene transition notes.
Pin map and wiring diagram. GPIO ↔ component for every zone; include WS2812 power notes.
BOM. Parts list aligned with the city’s shared BOM.
Sensor handling. Threshold, filter, and timeout logic for LDR and presence.
Full-stack interface. Messages for ambient, presence, and scene per zone, plus 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. “bright ambient → low output”, “dark idle”, “presence zone A only”, “presence both”, “override scene”.

Realisation — minimum evidence

Small test sketches (or a short test log) showing you verified parts separately: LDR, PIR, zone A strip, OLED, zone B — before integration.
Work on the city GitLab project: proven multi-zone 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 zones labelled.
Demo script (numbered steps) matching your video or live assessment, covering at least two zones 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. PIR range, strip current limits, 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 zones you control and ambient / presence rules are described in plain language.
Scope is explicit: this challenge delivers multi-zone adaptive park lighting on your city tile (at least two zones), integrated into shared firmware — not a single-LED 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 for coordinated zones, including how per-zone 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 multi-zone state machine plus timing rules that match the intended firmware behaviour.
Pin map, wiring diagram, and BOM cover every controlled zone and match the realised prototype (or differences are documented with reason).
Fail-safe behaviour is designed explicitly (stable idle, timeouts, documented strip power).
The data/control interface for full-stack is specified with example messages per zone.

Realisation

The prototype demonstrates LDR dimming, presence brightening, WS2812 scenes, and OLED status on at least two zones.
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.
Sensor input is filtered; light 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 zone A, zone B, ambient change, and at least one edge case (e.g. brief PIR glitch, override).
Repository README explains how to build, flash, and run the multi-zone 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, multi-zone lighting, 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 one pole. Two sprints mean a multi-zone result; one strip scene alone is not enough.
WS2812 power. Do not power a strip only from a weak 3V3 pin; document a safe supply.
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 presence on other zones. Prefer millis()-based state machines or timers.
LDR flicker. Smooth or threshold ambient readings so scenes do not strobe.
PIR retrigger. Define hold time so walking past does not create a frantic blink.
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, zones, or interface messages during realisation.

Key points

Core task: dim with ambient light and brighten on presence across at least two zones on your city tile.
Because this is Sprint 1-2, the delivered system is multi-zone, not a single lamp.
Test small parts in separate Arduino sketches; integrate only what works into one shared firmware.
Expose per-zone 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 zone); Sprint 2 emphasises multi-zone design & realisation.
Mains lighting / CV tracking 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.