Smart Traffic Light System

Picture a crossing in your Learning Group's city. Cars can arrive from more than one side. Your system detects vehicles per approach and updates the traffic lights so traffic can move without conflicting greens. When no cars are present, lights return to a defined idle state. That is embedded logic: several sensor inputs drive coordinated actuator outputs in real time.

In this challenge you design and build a smart traffic light system for your Learning Group city tile: detect cars on different sides of the crossing and control the matching lights. Because this challenge spans two sprints, the delivered result is a multi-side system — not a single approach with one light. 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 Traffic Light System (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, one light). Your delivered system must cover different sides of the crossing — each with detection and a light — and keep conflicting directions from being green at the same time.

Challenge

Your Learning Group city needs a multi-side car-detected traffic light system on a city tile. Vehicles can arrive from different approaches; each side you control needs detection and a traffic signal, and the phases must stay safe (no conflicting greens). 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 sides of the crossing do you control (at least two)? Where is each car detected? When is each light red vs green, and how do the sides take turns? Write clear rules, e.g. “North–south green only when a car is detected on that axis and east–west is red.” Agree which tile template you use and how this challenge fits the city plan.
Research. Compare realistic ways to detect a car per approach and to drive multiple traffic lights, plus how to coordinate phases across sides. Include how you will expose sensor data and light 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 and light outputs per side, coordination approach, 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 sides, sensor 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 (one light, one sensor, then a second side, then coordination) before you merge working pieces into the shared city firmware on GitLab main. Keep each test sketch tiny. Then demonstrate: lights on different sides respond to detection without conflicting greens. 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 traffic light system placed on that tile (or a clear bench stand-in while the tile is cut). Prefer a tile that supports a crossing (e.g. crossroads or T-junction).
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-side traffic-light behaviour included.
Control of at least two sides of the crossing. For each side you control:
- A traffic signal with red, yellow, and green outputs (separate LEDs or a suitable module), and
- A vehicle detection sensor aimed at that approach (e.g. ultrasonic or IR).
Firmware that updates each side’s light based on detection and coordinates the sides so conflicting directions are not green together. Example pattern:
- Idle: all controlled sides red (or a documented default),
- A detected car on side A may get green only while conflicting side B stays red,
- After side A finishes (car gone or timeout), side B can be served if a car is waiting.
A documented phase sequence for the multi-side system (which sides may be green together, yellow transitions, and “car gone” behaviour). Keep it simple and explain your choice.
Filtering or debouncing on each sensor signal and timeouts so the system cannot get stuck serving one side forever.
A documented data and control interface for full-stack developers: sensor values and light states per side, plus commands that can override or request a light state (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 approach on a full crossroads tile (still with clear conflict rules).
Serial debug output showing per-side sensor values and light states.
A simple lane model (tape, cardboard) so sensor aim per side is obvious in demos.
A timing table for how long each side may hold green when a car is detected vs not.
Validation with a second object per lane to show the sensor distinguishes a “car” from an empty approach.
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:

Pedestrian buttons, pedestrian phases, or crosswalk logic.
Cyclists as a separate mode, left-turn pockets, or adaptive city-wide networks beyond your tile.
Production PCB fabrication or road-certified traffic controllers.
Computer vision / ML vehicle counting.
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 red on a side when its sensor is unsure or idle; never leave two conflicting sides green.
Predictable rules. Document exactly when each side’s light changes relative to detection and to the other side.
Clear demo script. Anyone in your Learning Group can show at least: empty crossing → safe idle; car on side A → A updates while B stays safe; car on side B → B can be served without conflicting with A.
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 (crossroads or T-junction work well) and sketch which sides you will control.
Agree on multi-side rules. For each side: where is the car detected, and when may that side go green? Write conflict rules in plain language (e.g. “East–west stays red while north–south is green”).
Inventory hardware. List what your studio kit provides (ESP32, LEDs, resistors, breadboard, sensors per side). Note gaps early and ask your coach. Start the city’s shared BOM.
Test in small sketches first. Create short Arduino sketches for one concern at a time (e.g. one R/Y/G set, one sensor, then a second side, 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-side topics/messages and an 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 sensors, light outputs, and phase coordination best fit a multi-side 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 side in sketches, then the second side, 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-side concept) and prove one approach in small sketches. In the second sprint you focus on design and realisation of the full multi-side system: second side, coordination, shared-firmware integration, and the full-stack interface.

Sprint	Focus	Outcome
1	Research & advise (+ first side in sketches)	Research report; advisory report; tile and sides chosen; conflict rules; hardware choice; draft per-side data/control interface; one side proven in a small test sketch
2	Design & realisation (multi-side)	Wiring diagram + pin map + multi-side state diagram; shared BOM updated; at least two sides coordinated in shared firmware on city GitLab `main`; demo of both sides (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	LEDs + resistors; optional relay module for “full size” lamps
Sensors	Ultrasonic (HC-SR04) or IR obstacle sensor — one detection path per controlled side
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-side vehicle detection and coordinated traffic-light control; comparison with criteria; recommendation for design	Research product
Advice	Decision document: chosen MCU role in shared firmware, sensors and lights per side, conflict/phase rules, full-stack data/control interface, and implementation order (one side → second side → coordination)	Advisory report

Suggested titles for Portflow

Research: Multi-side vehicle detection for smart traffic light system
Advice: Coordinated multi-side traffic light 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 sides, circuit/wiring diagram, pin assignment table, traffic-light state machine for coordinated sides (diagram + description), timing parameters, software module overview for the shared firmware, per-side data/control interface for full-stack, contribution to the city BOM, and test plan
Prototype realisation	Design & Realise	Working multi-side 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 cars are detected on different sides

Suggested titles for Portflow

Design: Smart Traffic Light System — multi-side hardware and firmware specification
Realisation: Smart Traffic Light System — multi-side prototype and validation

System design — minimum contents

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

Requirements. Per-side rules for car detected / no car, and conflict rules between sides; how this fits the city Requirements.
Architecture diagram. MCU, sensors and light outputs per side, power, and the path to full-stack (protocol boundary).
State machine. States that cover idle, serving side A, serving side B (and more if you add sides), yellow transitions, and optional override commands — never two conflicting greens.
Timing table. Max green per side; what happens if a car stays in front of a sensor; how the next waiting side is chosen.
Pin map and wiring diagram. GPIO ↔ component for every side; include resistor values for LEDs.
BOM. Parts list aligned with the city’s shared BOM (count sensors and light sets per side).
Sensor handling. Threshold, debounce/filter, and timeout logic per side.
Full-stack interface. Messages for sensor data and light state per side, plus 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 → idle red”, “car on side A only”, “car on side B only”, “cars waiting on both sides (no conflict)”, “override forces red”.

Realisation — minimum evidence

Small test sketches (or a short test log) showing you verified parts separately: one side’s lights, one sensor, second side, then coordination — before integration.
Work on the city GitLab project: proven multi-side 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 sides labelled.
Demo script (numbered steps) matching your video or live assessment, covering at least two sides 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 sides, 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 sides you control and car-detection / conflict rules are described in plain language (when each light is red vs green, and which sides may never be green together).
Scope is explicit: this challenge delivers a multi-side traffic light system on your city tile (at least two approaches), integrated into shared firmware — not a single-side demo, pedestrians, 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 sides, including how per-side 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-side state machine plus timing rules that match the intended firmware behaviour.
Pin map, wiring diagram, and BOM cover every controlled side and match the realised prototype (or differences are documented with reason).
Fail-safe behaviour is designed explicitly (default safe state, timeouts, stuck-side recovery, no conflicting greens).
The data/control interface for full-stack is specified with example messages per side.

Realisation

The prototype demonstrates red–yellow–green outputs on at least two sides and changes lights based on car detection without conflicting greens.
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 side; 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 side A, side B, both waiting / hand-over, and at least one edge case (e.g. brief false trigger, car removed mid-phase, override).
Repository README explains how to build, flash, and run the multi-side 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-side 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 side. Two sprints mean a multi-side result; one approach alone is not enough for this challenge.
Conflicting greens. Always define which sides may never be green together; test that case on purpose.
Everything in main firmware. Develop and test parts in small Arduino sketches first (side A, side 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 sides. Prefer millis()-based state machines or timers.
Sensor aim / crosstalk. Sensors for different sides can interfere; document placement on the tile and test both occupied.
No clear idle state. Define what happens when no cars are present (typically all red on controlled sides).
Current limits. Calculate LED resistor values; do not drive high-power lamps directly from GPIO.
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, sides, or interface messages during realisation.

Key points

Core task: detect cars on different sides → update the matching lights safely on your city tile.
Because this is Sprint 1-2, the delivered system is multi-side (at least two approaches), not a single light.
Test small parts in separate Arduino sketches; integrate only what works into one shared firmware.
Expose per-side 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 side); Sprint 2 emphasises multi-side design & realisation.
Pedestrians 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.