Bus Stop (ABRI)

Picture a bus stop shelter (ABRI) on your Learning Group's city tile. Travellers need next-bus information, the stop may show an ad or info mode, and the shelter door should open only for users who request access. That is embedded logic: a timer/display, a second display mode, and a controlled entrance work together as one stop.

In this challenge you design and build a bus stop (ABRI) for your Learning Group city tile: show next-bus countdown or timer info, support an ad/display mode, and control shelter access with a servo door. Because this challenge spans two sprints, the delivered result is a multi-feature stop — not a single countdown LED. 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 - Bus Stop (ABRI) (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 (countdown, door, waiting user). Your delivered system must cover next-bus info, ad/display mode, and shelter access as coordinated features.

Challenge

Your Learning Group city needs a multi-feature bus stop (ABRI) on a city tile. Travellers see next-bus info, the stop can switch to an ad/display mode, and a servo door grants shelter access only on user request (button or RFID-stand-in button). 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. What does “next bus” mean on your prototype (countdown timer, fixed schedule loop, or stub from full-stack)? When does ad mode show? Who may open the door? Write clear rules. Agree which tile template you use and how this challenge fits the city plan.
Research. Compare realistic ways to show countdown/info (OLED or 7-seg), switch display modes, and drive a shelter door (servo) with access request. Include how you will expose stop status 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, display(s), door, access input, 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 info / ad / access, 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 (countdown display, ad mode switch, door servo, button) before you merge working pieces into the shared city firmware on GitLab main. Keep each test sketch tiny. Then demonstrate: info display, ad mode, and door access work together. 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 bus stop 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-feature ABRI behaviour included.
A multi-feature bus stop that includes all of the following:
- Next-bus info on OLED and/or 4-character 7-segment (countdown timer or repeating schedule stand-in is fine),
- An ad / alternate display mode (second screen content, LED strip scene, or toggled OLED page),
- Shelter access: servo door plus button (or RFID-stand-in button) so the door opens only on request and closes after a timeout.
Firmware that coordinates info, ad mode, and access. Example pattern:
- Idle: show next-bus countdown; door closed,
- Periodically or on command: switch to ad mode briefly, then back to bus info,
- Access request → door opens, then closes after timeout.
A documented behaviour sequence for display modes and door timing. Keep it simple and explain your choice.
Debouncing on the access button and timeouts so the door cannot stay open forever.
A documented data and control interface for full-stack developers: next-bus fields (or timer), display mode, door state, plus commands that can set ETA, force ad mode, or request door open (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. A local countdown stub is acceptable until full-stack provides ETAs.
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 second display (OLED for ads, 7-seg for countdown) running in parallel.
Serial debug output showing mode, countdown, and door state.
A simple shelter model (cardboard) so the door is obvious in demos.
A PIR inside the shelter so lights or display brighten when someone waits.
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:

Live city transit APIs as a hard requirement (stubs and timers are enough).
Real RFID security certification or payment for shelter access.
Computer vision / ML crowd counting.
Production PCB fabrication.
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 a real transit shelter:

Default to closed on the door when idle; default display to next-bus info when mode is unclear.
Predictable rules. Document exactly when ad mode appears and when the door opens/closes.
Clear demo script. Anyone in your Learning Group can show at least: countdown/info updates; switch to ad mode and back; button opens door then auto-closes.
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 display, door, and button placement on the ABRI.
Agree on multi-feature rules. When does ad mode run, and how long does the door stay open? Write rules in plain language.
Inventory hardware. List what your studio kit provides (ESP32, OLED and/or 7-seg, servo, button, 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. countdown on display, ad page toggle, servo door, button debounce). 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 (ETA/mode/door messages). 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 display hardware, door actuator, and mode-switching approach best fit a multi-feature ABRI tile given GPIO limits and full-stack ETA integration?
Create your Learning Goal in Portflow. Link the product deliverables you plan to submit. Follow Learning Goal.
Integrate only what works. Prove display or door in sketches, then the remaining features, then 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 the multi-feature concept) and prove one subsystem (e.g. countdown display or door) in small sketches. In the second sprint you focus on design and realisation of the full multi-feature system: remaining features, coordination, shared-firmware integration, and the full-stack interface.

Sprint	Focus	Outcome
1	Research & advise (+ first subsystem in sketches)	Research report; advisory report; tile and features chosen; display/door rules; hardware choice; draft data/control interface; one subsystem proven in a small test sketch
2	Design & realisation (multi-feature)	Wiring diagram + pin map + ABRI state diagram; shared BOM updated; next-bus info + ad mode + door access coordinated 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 (door); optional LEDs / WS2812 for ad accent
Display	OLED and/or 4-character 7-segment
Sensors / input	Button (access / RFID stand-in); optional PIR for presence
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 next-bus display, mode switching, and shelter access control; comparison with criteria; recommendation for design	Research product
Advice	Decision document: chosen MCU role in shared firmware, display(s), door, access input, mode rules, full-stack data/control interface, and implementation order (one feature → next → coordination)	Advisory report

Suggested titles for Portflow

Research: Display and access options for bus stop (ABRI)
Advice: Multi-feature ABRI info, ad mode, and door 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 multi-feature ABRI, circuit/wiring diagram, pin assignment table, ABRI state machine (diagram + description), timing parameters, software module overview for the shared firmware, data/control interface for full-stack, contribution to the city BOM, and test plan
Prototype realisation	Design & Realise	Working multi-feature 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 info, ad mode, and door access

Suggested titles for Portflow

Design: Bus Stop (ABRI) — multi-feature hardware and firmware specification
Realisation: Bus Stop (ABRI) — multi-feature prototype and validation

System design — minimum contents

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

Requirements. Rules for next-bus info, ad mode, and door access; how this fits the city Requirements.
Architecture diagram. MCU, display(s), servo door, button, power, and the path to full-stack (protocol boundary).
State machine. States that cover bus-info, ad mode, door open/closed, and optional override commands.
Timing table. Countdown source; ad-mode duration; door open timeout.
Pin map and wiring diagram. GPIO ↔ component; include resistor values for LEDs/buttons.
BOM. Parts list aligned with the city’s shared BOM.
Input handling. Debounce on access button; how ETA stubs update the display.
Full-stack interface. Messages for ETA/mode/door, 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. “countdown runs”, “ad mode toggles”, “button opens door”, “door auto-closes”, “override sets ETA”.

Realisation — minimum evidence

Small test sketches (or a short test log) showing you verified parts separately: display countdown, ad mode, door, button — before integration.
Work on the city GitLab project: proven multi-feature 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 features labelled.
Demo script (numbered steps) matching your video or live assessment, covering info + ad mode + door 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. timer-only ETA, 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 display modes and door access rules are described in plain language.
Scope is explicit: this challenge delivers a multi-feature ABRI on your city tile (next-bus info + ad mode + door), integrated into shared firmware — not a single-display 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 features, including how stop 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-feature state machine plus timing rules that match the intended firmware behaviour.
Pin map, wiring diagram, and BOM cover display(s), door, and access input and match the realised prototype (or differences are documented with reason).
Fail-safe behaviour is designed explicitly (door default closed, timeouts, predictable display mode).
The data/control interface for full-stack is specified with example messages for ETA, mode, and door.

Realisation

The prototype demonstrates next-bus info, ad/display mode, and servo door access together.
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.
Button input is debounced; mode and door 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 info mode, ad mode, door open/close, and at least one edge case (e.g. double button press, override ETA).
Repository README explains how to build, flash, and run the multi-feature 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-feature coordination, 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 feature. Two sprints mean info + ad mode + door; a lone countdown is not enough.
Door left open. Always define auto-close timeout; test it on purpose.
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 live ETAs exist.
Blocking delay() everywhere. Long delay() calls freeze countdown and door logic. Prefer millis()-based state machines or timers.
Display I2C conflicts. Document addresses if you use OLED plus other I2C devices.
Servo power. Do not starve the MCU; power the door 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, timings, modes, or interface messages during realisation.

Key points

Core task: show next-bus info, support ad mode, and control shelter access on your city tile.
Because this is Sprint 1-2, the delivered system is multi-feature, not a single display.
Test small parts in separate Arduino sketches; integrate only what works into one shared firmware.
Expose stop 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 multi-feature design & realisation.
Live transit APIs as a hard dependency and city-wide networks beyond your tile 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.