Smart Traffic Light System
Picture a quiet approach to a crossing in your Learning Group's city. A car rolls up — the light is red. Your system detects the car and updates the traffic light to green so it can pass through. When the car is gone, the light returns to red. That is embedded logic: a sensor input drives an actuator output in real time.
In this challenge you design and build a smart traffic light prototype that does exactly that — detect a car and control the traffic light. Your firmware runs on a microcontroller, reads a vehicle sensor, and switches the signal accordingly. You work through research, advice, design, and realisation and deliver evidence for your Sprint 1–2 Learning Goal.
Your Learning Goal title in Portflow
Use: Sprint 1 - 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 behaviour you are aiming for — top view, simple shapes: a blue round car approaches the crossing, waits at a red light, then drives through when the light turns green.
Challenge
Your Learning Group builds a small car-detected traffic light demonstrator: when a vehicle is present at the approach, the light must respond; when no vehicle is present, it must return to a defined idle state.
You will deliver a working prototype and the documents that justify and explain it. Work in this order:
- Understand the problem — Where is the car detected (stop line, lane segment)? When should the light be red vs green? Write this as two or three clear rules, e.g. “Red when no car; green when a car is detected at the approach.”
- Research — Compare realistic ways to detect a car (e.g. ultrasonic, infrared obstacle, inductive loop simulation) and to drive a traffic light (GPIO LEDs, relay modules). Use datasheets, not only webshop text.
- Advise — Recommend one architecture: microcontroller, vehicle sensor, light outputs, and software approach. State what you are not building in this sprint.
- Design — Specify hardware (wiring, pin map) and software (state machine, sensor thresholds, timing) so someone else could rebuild your system.
- Realise — Build, test, and demonstrate: show the light changing when a car is present vs absent. Log behaviour (Serial Monitor, table, or short video).
Minimum scope (Sprint 1–2)
Your prototype must include:
- A microcontroller (e.g. ESP32 or Arduino-class board) running your own firmware.
- A traffic signal with red, yellow, and green outputs (separate LEDs or a suitable module).
- A vehicle detection sensor aimed at the approach where the car waits (e.g. ultrasonic or IR).
- Firmware that updates the traffic light based on car detection — for example:
- Red while no car is detected; green when a car is detected at the approach, or
- Red by default; switch to green after a car is detected and held for a defined time.
- A documented phase sequence (how red, yellow, and green relate to “car detected” and “car gone”) — keep it simple and explain your choice.
- Filtering or debouncing on the sensor signal and timeouts so the system cannot get stuck in one state forever.
Recommended scope
If you have time, add one or more of:
- Serial debug output showing sensor values and current light state.
- A simple lane model (tape, cardboard) so the sensor aim is obvious in demos.
- A timing table for how long each light state lasts when a car is detected vs not.
- Validation with a second object (e.g. box vs no object) to show the sensor distinguishes a “car” from an empty lane.
Out of scope for this challenge
These are not part of this sprint:
- Pedestrian buttons, pedestrian phases, or crosswalk logic.
- Multiple approaches, cyclists, or full intersection control.
- Production PCB fabrication or road-certified traffic controllers.
- Computer vision / ML vehicle counting.
- Cloud dashboards, MQTT, or city-wide traffic integration.
Demo and safety context
Treat the prototype as lab equipment, not street-legal infrastructure:
- Default to red when the sensor is unsure or idle.
- Predictable rules — document exactly when the light changes relative to car detection.
- Clear demo script — anyone in your Learning Group can show “no car → red”, “car present → light updates”.
Starting points
Use these concrete first steps in the first week:
- Agree on detection rules — Sketch the approach lane and mark where the car is detected. Write your light rules in plain language (e.g. “Green only when the sensor reports a car within 30 cm for at least 1 s”).
- Inventory hardware — List what your studio kit provides (ESP32, LEDs, resistors, breadboard, ultrasonic or IR sensor). Note gaps early and ask your coach.
- Blink one LED — Confirm toolchain: IDE, upload,
Serial.begin, one GPIO. See First ESP32 project. - Draft your research question — Example: Which vehicle-detection sensor best fits our lane prototype given range, false triggers, and wiring constraints?
- Create your Learning Goal in Portflow — Link the product deliverables you plan to submit. Follow Learning Goal.
Suggested sprint timeline
| Week | Focus | Outcome |
|---|---|---|
| 1 | Context, research, hardware check | Research report draft; block diagram on whiteboard |
| 2 | Advice, detailed design | Advisory report; pin map + state diagram |
| 3 | Implementation | Firmware modules, bench tests per phase |
| 4 | Integration, demo, reflection | Working demo; Portflow evidence linked; reflection |
Adjust with your Scrum ceremonies — see Scrum.
Tools, frameworks, and hardware
| Area | Suggestions |
|---|---|
| Microcontroller | ESP32 / ESP32-S3 DevKit or Arduino Uno (justify choice in research) |
| Actuators | LEDs + resistors; optional relay module for “full size” lamps |
| Sensors | Ultrasonic (HC-SR04) or IR obstacle sensor — for car detection at the approach |
| IDE | Arduino IDE or PlatformIO |
| Version control | GitLab repo with tagged milestones per merge requests |
| Documentation | Markdown in repo + PDF export for Portflow if required |
Profile knowledge worth revisiting:
- Arduino overview
- Sensors and actuators together
- Sketch structure and timing
- LED component
- Microcontrollers
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 vehicle-detection and traffic-light control options; comparison with criteria; recommendation for design | Research product |
| Advice | Decision document: chosen MCU, car sensor, light outputs, detection rules, and implementation order | Advisory report |
Suggested titles for Portflow
- Research: Vehicle detection for smart traffic light prototype
- Advice: Car-detected 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, requirements, block diagram, circuit/wiring diagram, pin assignment table, traffic-light state machine (diagram + description), timing parameters, software module overview, bill of materials (BOM), and test plan |
| Prototype realisation | Design & Realise | Working breadboard prototype, source code in GitLab, README with build/upload steps, and validation evidence (test log, Serial capture, or short demo video) showing the light change when a car is detected vs not detected |
Suggested titles for Portflow
- Design: Smart Traffic Light System — hardware and firmware specification
- Realisation: Smart Traffic Light System — prototype and validation
System design — minimum contents
Your design document should let a peer rebuild the system without guessing:
- Requirements — When the light is red vs green/yellow relative to car detected / no car.
- Architecture diagram — MCU, vehicle sensor, light outputs, power.
- State machine — States such as
NO_CAR_RED,CAR_DETECTED,GREEN, and transitions driven by the sensor. - Timing table — How long each light state lasts; what happens if the car stays in front of the sensor.
- Pin map — GPIO ↔ component; include resistor values for LEDs.
- Sensor handling — Threshold, debounce/filter, and timeout logic.
- Test plan — e.g. “empty lane → red”, “object in lane → light updates”, “object removed → red returns”.
Realisation — minimum evidence
- Repository tag or commit hash assessed by your coach.
- Photo or diagram of the physical build.
- Demo script (numbered steps) matching your video or live assessment.
- Honest known limitations (e.g. ultrasonic crosstalk, no battery backup).
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 approach lane and car-detection rules are described in plain language (when the light is red vs green).
- Scope is explicit: this sprint is car detection + traffic light only — not pedestrians or full intersections.
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.
- Component and approach choices are supported by datasheets or comparable evidence, not only opinion.
Design
- The design document is self-contained and includes a state machine plus timing rules that match the intended firmware behaviour.
- Pin map and wiring match the realised prototype (or differences are documented with reason).
- Fail-safe behaviour is designed explicitly (default safe state, timeouts, stuck-phase recovery).
Realisation
- The prototype demonstrates red–yellow–green outputs and changes the light based on car detection (present vs absent).
- Firmware is readable: meaningful names, constants for thresholds/timings, no unexplained magic numbers.
- Sensor input is filtered or debounced; light changes are observable via Serial log or demo script.
- Validation evidence covers car detected, no car, and at least one edge case (e.g. brief false trigger, car removed mid-phase).
- Repository README explains how to build, flash, and run the demo.
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).
- Scrum artefacts (backlog items, MRs) show incremental delivery — not a single last-minute commit.
Focus points
Watch out for these common issues while you work:
- Blocking
delay()everywhere — Longdelay()calls miss sensor changes. Prefermillis()-based state machines or timers. - Sensor aim — Ultrasonic or IR sensors angled wrong read the wrong spot; document placement in your design.
- No clear idle state — Define what happens when no car is present (typically red).
- 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, or timings during realisation.
Key points
- Core task: detect a car → update the traffic light.
- Deliver four products: research, advice, system design, and prototype realisation.
- Work research → advice → design → realise; each step feeds the next.
- Pedestrians and multi-arm intersections are out of scope for this challenge.
- Link everything to your Learning Goal in Portflow and reflect at the end of the sprint.