Parking Area

Picture a parking lot on your Learning Group's city tile. Drivers need to know how many spots are free, and an entrance gate should open only when space is available. Your system measures which spots are in use, shows free capacity, and controls the gate. That is embedded logic: several occupancy inputs drive a display and a coordinated actuator in real time.

In this challenge you design and build a parking area for your Learning Group city tile: detect occupancy of at least two spots, show free spots, and control an entrance gate. Because this challenge spans two sprints, the delivered result is a multi-spot system — not a single bay with one 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 - Parking Area (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 (one car, gate, free-spot display). Your delivered system must cover at least two parking spots — each with occupancy sensing — plus the entrance display and gate, and keep the gate closed when the lot is full.

Challenge

Your Learning Group city needs a multi-spot parking area on a city tile. Drivers see how many spots are free; a gate opens when space is available and stays closed when the lot is full. Each spot you control needs occupancy sensing. 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. How many spots do you control (at least two)? How is each spot marked occupied vs free? When may the gate open? How is free capacity shown (OLED, 7-segment, or LEDs)? Write clear rules, e.g. “Gate opens only while free spots > 0.” Agree which tile template you use and how this challenge fits the city plan.
Research. Compare realistic ways to detect occupancy per spot, drive a gate (servo), and show free spots, plus how to keep counts consistent. Include how you will expose spot status and gate controls to the full-stack side (protocol options). Use datasheets and cite resources for decisions.
Advise. Recommend one architecture: microcontroller role in the shared city firmware, sensors per spot, gate and display, 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 spots, thresholds, gate 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 (one sensor, display, servo gate, then a second spot, then coordination) before you merge working pieces into the shared city firmware on GitLab main. Keep each test sketch tiny. Then demonstrate: free-spot display and gate respond to occupancy on different spots. 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 parking area placed on that tile (or a clear bench stand-in while the tile is cut). Prefer a tile that has room for an entrance and bay layout.
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-spot parking behaviour included.
Control of at least two parking spots. For each spot you control:
- An occupancy sensor (e.g. ultrasonic, IR, or a button as a clear stand-in for “car present”), and
- A visible occupied / free indication (LED or part of a shared display).
An entrance gate driven by a servo (SG90 or similar) that opens when free capacity exists and closes when the lot is full (or after a timeout / “car entered” rule you document).
An entrance display of free spots (OLED, 4-character 7-segment, or a clear LED count) that updates when occupancy changes.
Firmware that updates free-spot count from per-spot detection and coordinates the gate with that count. Example pattern:
- Idle: gate closed (or documented default), display shows current free count,
- A free spot may allow the gate to open when a vehicle approaches (or on request),
- When all spots are occupied, the gate stays closed and the display shows zero free.
A documented behaviour sequence for enter / occupy / free-up (gate timing, debounce, “spot freed” behaviour). Keep it simple and explain your choice.
Filtering or debouncing on each sensor signal and timeouts so the gate cannot chatter open/closed forever.
A documented data and control interface for full-stack developers: occupancy and free count per spot, plus commands that can override gate or request status (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 or fourth spot with the same occupancy rules.
Serial debug output showing per-spot status and free count.
A simple bay model (tape, cardboard) so sensor aim per spot is obvious in demos.
An approach sensor at the entrance (ultrasonic or button) so the gate only opens when a car is waiting.
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:

Payment, barriers with RFID payment, or booking apps.
Licence-plate recognition or computer vision / ML occupancy.
Multi-level garage lifts or city-wide parking networks beyond your tile.
Production PCB fabrication or commercial parking controllers.
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-legal infrastructure:

Default to closed on the gate when occupancy is unsure or the lot is full; never leave the gate stuck open with zero free spots.
Predictable rules. Document exactly when the gate opens/closes relative to free count and detection.
Clear demo script. Anyone in your Learning Group can show at least: empty lot → free count correct and gate can open; occupy spot A → count drops; occupy all spots → gate stays closed; free a spot → count recovers.
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 which spots and where the gate and display sit.
Agree on multi-spot rules. For each spot: how is occupancy detected, and when may the gate open? Write rules in plain language (e.g. “Gate opens only while free spots > 0”).
Inventory hardware. List what your studio kit provides (ESP32, servo, display, breadboard, sensors per spot). 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. one occupancy sensor, OLED/7-seg count, servo sweep, then a second spot, then coordination). 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-spot topics/messages and a gate override example). 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 occupancy sensors, gate actuator, and free-spot display best fit a multi-spot tile given GPIO limits, false triggers, 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 spot in sketches, then the second spot, then gate + display 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-spot concept) and prove one subsystem (e.g. one spot + display or gate) in small sketches. In the second sprint you focus on design and realisation of the full multi-spot system: remaining spots, gate 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 spots chosen; occupancy/gate rules; hardware choice; draft per-spot data/control interface; one subsystem proven in a small test sketch
2	Design & realisation (multi-spot)	Wiring diagram + pin map + multi-spot state diagram; shared BOM updated; at least two spots plus gate and display coordinated in shared firmware on city GitLab `main`; demo of both spots (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 (gate); LEDs + resistors; optional buzzer for “lot full”
Display	OLED and/or 4-character 7-segment for free-spot count
Sensors	Ultrasonic (HC-SR04), IR, or buttons as stand-ins — one occupancy path per spot; optional LDR or PIR at entrance
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 multi-spot occupancy detection, gate control, and free-spot display; comparison with criteria; recommendation for design	Research product
Advice	Decision document: chosen MCU role in shared firmware, sensors per spot, gate and display, occupancy rules, full-stack data/control interface, and implementation order (one spot → second spot → coordination)	Advisory report

Suggested titles for Portflow

Research: Multi-spot occupancy sensing for parking area
Advice: Coordinated multi-spot parking gate and display 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 spots, circuit/wiring diagram, pin assignment table, parking state machine for gate and occupancy (diagram + description), timing parameters, software module overview for the shared firmware, per-spot data/control interface for full-stack, contribution to the city BOM, and test plan
Prototype realisation	Design & Realise	Working multi-spot 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 when spots are occupied on different bays

Suggested titles for Portflow

Design: Parking Area — multi-spot hardware and firmware specification
Realisation: Parking Area — multi-spot prototype and validation

System design — minimum contents

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

Requirements. Per-spot rules for occupied / free, and gate rules vs free count; how this fits the city Requirements.
Architecture diagram. MCU, sensors per spot, gate servo, display, power, and the path to full-stack (protocol boundary).
State machine. States that cover idle/closed, open when free, full/closed, and optional override commands — never open indefinitely with zero free spots.
Timing table. Gate open duration; what happens if a car stays in a bay; how free count updates.
Pin map and wiring diagram. GPIO ↔ component for every spot, gate, and display; include resistor values for LEDs.
BOM. Parts list aligned with the city’s shared BOM (count sensors per spot).
Sensor handling. Threshold, debounce/filter, and timeout logic per spot.
Full-stack interface. Messages for occupancy and free count per spot, plus gate controls/overrides; 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. “all empty → free count N”, “occupy spot A only”, “occupy all → gate closed”, “free a spot → gate may open”, “override forces closed”.

Realisation — minimum evidence

Small test sketches (or a short test log) showing you verified parts separately: one spot’s sensor, display, gate servo, second spot, then coordination — before integration.
Work on the city GitLab project: proven multi-spot 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 spots labelled.
Demo script (numbered steps) matching your video or live assessment, covering at least two spots, the gate, the display, 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 crosstalk between spots, 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 spots you control and occupancy / gate rules are described in plain language (when the gate may open, and how free count is computed).
Scope is explicit: this challenge delivers a multi-spot parking area on your city tile (at least two spots plus gate and display), integrated into shared firmware — not a single-bay 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 spots, including how per-spot 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-spot state machine plus timing rules that match the intended firmware behaviour.
Pin map, wiring diagram, and BOM cover every controlled spot, gate, and display and match the realised prototype (or differences are documented with reason).
Fail-safe behaviour is designed explicitly (default closed when full/unsure, timeouts, no stuck-open gate).
The data/control interface for full-stack is specified with example messages per spot.

Realisation

The prototype demonstrates occupancy on at least two spots, a free-spot display, and a servo gate that respects capacity.
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 or debounced per spot; gate and display 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 spot A, spot B, lot full, spot freed, and at least one edge case (e.g. brief false trigger, override).
Repository README explains how to build, flash, and run the multi-spot 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, safety, multi-spot 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 spot. Two sprints mean a multi-spot result; one bay alone is not enough for this challenge.
Gate vs count mismatch. Always keep free count and gate rules consistent; test “full lot” on purpose.
Everything in main firmware. Develop and test parts in small Arduino sketches first (spot A, display, gate, spot B, then coordination); 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 sensor changes on other spots. Prefer millis()-based state machines or timers.
Sensor aim / crosstalk. Sensors for different spots can interfere; document placement on the tile and test both occupied.
No clear full state. Define what happens when free count is zero (typically gate closed, display shows 0).
Servo power. Do not starve the MCU; power the 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, spots, or interface messages during realisation.

Key points

Core task: detect occupancy on different spots → update free-spot display and gate safely on your city tile.
Because this is Sprint 1-2, the delivered system is multi-spot (at least two bays plus gate and display), not a single sensor demo.
Test small parts in separate Arduino sketches; integrate only what works into one shared firmware.
Expose per-spot 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-spot design & realisation.
Payment / CV and city-wide parking 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.