Github Repo: https://github.com/KoukiXia/Emergency-Vehicle-Traffic-Preemption-System

Figure 1. Physical deployment concept. The Ambulance Unit (foreground) carries the GPS antenna, emergency-mode toggle, OLED link-status display, and LoRa radio. The Intersection Unit (mounted on the signal pole, cutaway shown inset) hosts the second ESP32, LoRa receiver, OLED, and buzzer, and drives a standard 4-approach signal head. The two communicate over LoRa at 868 MHz.

In Cairo and most Egyptian cities, ambulances lose critical minutes stuck in gridlock. Published figures put the average ambulance response time in Egypt at 8 to 15 minutes, and it is common to see emergency vehicles trapped behind traffic with sirens blaring. For conditions like cardiac arrest, stroke, or major trauma, every minute of delay measurably reduces survival rate. Meanwhile, cities like Dubai, several US metros, and parts of Germany and the UK already deploy Emergency Vehicle Preemption (EVP) systems (Opticom, EMTRAC, Commsignia V2X) that turn intersections green for approaching emergency vehicles, cutting response times by 14 to 23 percent. No comparable system is deployed in Egypt.

GreenWave is a prototype Emergency Vehicle Preemption system built around two ESP32 microcontrollers running FreeRTOS, connected by a LoRa radio link. An "ambulance unit" carries a GPS module, an inertial/speed sensor, and a physical "Emergency Mode" switch. When the ambulance is in emergency mode and its GPS-derived speed and heading indicate it is approaching an instrumented intersection, it broadcasts a signed preemption request packet over LoRa. A stationary "intersection unit" runs a full 4-phase traffic light state machine on a second ESP32 with red/yellow/green LEDs for each approach. On receiving a valid, in-range, directionally-relevant preemption request, the intersection controller safely aborts its current phase (respecting a minimum-green and mandatory all-red clearance), grants a green wave to the approach carrying the ambulance, holds it until the vehicle clears, then returns to normal cycle.

The project demonstrates hardware-software co-design (GPS + LoRa + actuated signal head), non-trivial real-time behavior (phase safety, clearance timing, preemption arbitration), an RTOS architecture with multiple concurrent tasks communicating through queues and event groups, and wireless V2I (vehicle-to-infrastructure) communication. Crucially, it is a safety-critical control problem: doing it wrong causes collisions, so the firmware must enforce interlocks that are genuinely non-trivial to design.

Emergency response times in Cairo are among the worst in the region. Contributing factors are well documented: chronic traffic congestion on arterial roads, narrow streets with few alternate routes, limited driver compliance with "move-over" laws, and the absence of any technological intervention at signalized intersections. Internationally, this problem was solved decades ago — Opticom IR preemption has been in US municipal deployments since the 1970s, GPS/radio preemption dominates modern US rollouts, Dubai's RTA has announced smart traffic signals that clear paths for ambulances as part of its 2026 smart-signal coverage target, and V2X-based preemption is being piloted by Ford and Commsignia across Europe. Egypt has none of this infrastructure. Our project addresses the core technical gap with a student-scale, open, inexpensive prototype that proves the concept end-to-end and can be scaled to a pilot corridor.

• United States — Opticom / EMTRAC / Miovision: The dominant commercial EVP stack. Original Opticom used 14 Hz strobe infrared emitters on the vehicle and roof-mounted IR detectors at the intersection. Modern Opticom uses GPS on the vehicle plus 900 MHz / 2.4 GHz FHSS radio, or cellular, communicating with the intersection controller cabinet. Cities including Minneapolis, Seattle, Roswell GA, and many others report 14 to 23 percent reductions in response time and measurable reductions in intersection crashes involving emergency vehicles.
• New York City: Uses a mix of legacy actuated signals and, in parts of Manhattan and the outer boroughs, the NYCDOT Midtown-in-Motion adaptive system. Formal GPS-based EVP is not yet city-wide; FDNY has piloted Opticom in limited corridors. NYC is often cited as a city where EVP would have large benefit but where retrofit cost on ~13,000 signals is the barrier.
• Europe — Germany / UK / EU V2X trials: Germany and the UK have long used inductive-loop and IR-based preemption on many fire-service corridors. The current direction is C-V2X / ITS-G5 standards: Ford and Commsignia have demoed C-V2X-equipped traffic lights that auto-green for approaching emergency vehicles. London alone sees ~2,000 ambulance-involved collisions a year, much of which V2X aims to reduce.
• Gulf — UAE (Dubai & Abu Dhabi): Dubai RTA's SCOOT and the upcoming UTC-UX Fusion system manage over 800 signalized intersections, and the UAE Ministry of Health has formally launched smart ambulances that turn signals green on their route and stream patient vitals to the receiving hospital. Abu Dhabi rolled out AI-driven smart traffic lights at key entry points of Sheikh Zayed bin Sultan Street. The Gulf is ahead of Egypt by roughly a decade on this specific technology.
• Egypt: No deployed EVP system found. Egypt recently unified its emergency hotline as "112" (2022), but ambulance dispatch still relies on human routing and drivers negotiating traffic manually. Reasons the technology is absent include (a) cost of retrofitting legacy fixed-time controllers, (b) no nationwide V2X standard or spectrum allocation, (c) fragmented authority between the Traffic Department, municipalities, and the Ministry of Health, and (d) no procurement track record forcing vendors into the market. This is exactly the sort of gap a student prototype can make visible.
• Alternative detection modalities we considered and rejected for scope: acoustic siren detection (microphone arrays at intersections — promising but noise-sensitive), computer-vision detection of flashing lights via a camera at the intersection (ML-heavy and too scope-inflating for an embedded course), pure cellular/MQTT via a cloud broker (works but adds infrastructure the lab does not need), and BLE (too short range to be realistic).

A production-grade city rollout of this system would be cloud-centralized: the ambulance would report its position and destination to a dispatch server, which would know the full road network, compute the route, and pre-arm every intersection along that route. This is how Miovision Opticom Cloud, EMTRAC, and the UAE smart-ambulance program actually work at the backend, and it is the right architecture once you have dozens of ambulances, hospital integration, and multi-vehicle arbitration to worry about.

We deliberately chose not to build the cloud version. The reasons are pedagogical and technical. A cloud deployment adds a server, a message broker, cellular SIMs, a database, a routing engine, and authentication — all of which is DevOps and web work, not embedded work. More importantly, the safety-critical go/no-go decision for a traffic signal must stay local to the intersection; any serious commercial deployment keeps the final decision at the edge so a network hiccup cannot cause an unsafe phase. The ambulance-to-intersection link we implement is exactly the "last hop" of a cloud architecture, and the state machine, authentication, and fail-safes we build are identical in both designs. Our prototype is a proper subset of a cloud deployment, not an alternative to it. As a stretch goal (see below) we optionally add a local laptop-based dispatch dashboard that simulates the cloud's role at toy scale, so the full architecture can be shown end to end in the final demo.

Two ESP32 nodes, FreeRTOS on both, LoRa as the V2I radio, GPS on the vehicle, a full actuated 4-phase signal head at the intersection. The ambulance unit fuses GPS speed, heading, and distance-to-intersection to decide when to issue a preemption request, then transmits an authenticated LoRa packet. The intersection unit runs a provably safe traffic light state machine with minimum-green, yellow, and all-red clearance intervals rigidly enforced. Preemption is handled as a high-priority event that can interrupt the normal cycle only at safe transition points.

Why LoRa: chosen because (a) it gives the 500 m to 2 km range that matches real EVP "advance warning" distance, (b) it is low-power and cheap (SX1276 modules ~USD 5 locally), (c) it does not need cellular infrastructure or a WiFi AP, which is realistic for a municipal deployment, and (d) it is a more interesting embedded exercise than short-range ESP-NOW. Fallback: if LoRa modules are not available in the CSCE workshop, we fall back to ESP-NOW (ESP32 native 2.4 GHz peer-to-peer), which offers ~200 m range and still demonstrates the V2I architecture cleanly. BLE was rejected because its effective range (30-50 m) is too short to model realistic approach timing.

Minimum Viable Product (MVP):

• Two ESP32 microcontrollers, each running FreeRTOS with at least four concurrent tasks.
• Ambulance Unit: NEO-6M (or NEO-M8N) GPS module, physical "Emergency Mode" toggle switch, status LED, LoRa SX1276 transmitter, small OLED (SSD1306) showing speed, heading, and link status.
• Intersection Unit: 12 LEDs arranged as a 4-approach signal head (R/Y/G × 4), LoRa SX1276 receiver, OLED showing current phase, a manual override button, and a buzzer that chirps when preemption is active.
• Full actuated traffic light state machine: North-South Green → NS Yellow → All-Red → East-West Green → EW Yellow → All-Red, with configurable minimum-green (5 s), yellow (3 s), and all-red clearance (2 s).
• Preemption protocol: when a valid, in-range, directionally-matched request arrives, the intersection gracefully transitions to the ambulance's approach green, holds it while the vehicle is within the clearance radius, then resumes the normal cycle.
• Anti-abuse: packets are authenticated with a shared-secret HMAC and include a monotonically increasing sequence number to prevent replay.
• Link health watchdog: if LoRa drops for more than 2 s during a preemption hold, the controller returns to safe default (all-red) before resuming.

Stretch Goals:

• Web dashboard (ESP32 AP or ThingSpeak) showing the ambulance's live GPS position, intersection state, and recent preemption events.
• Second intersection node to demonstrate a true "green wave" along a corridor.
• Local "dispatch simulator" dashboard (laptop on WiFi, MQTT or WebSocket) that logs every preemption event and shows the ambulance on a live map — a toy-scale stand-in for the cloud layer a production system would have.
• Vehicle speed-prediction to time the green so the ambulance does not have to slow down.
• SD card event log on the intersection unit for postmortem analysis.
• 3D-printed enclosures for both units.

Out of Scope:

• Integration with any real municipal traffic controller cabinet (NEMA TS-2, 2070, MMU). We simulate the signal head with LEDs.
• Legal road deployment.
• Pedestrian phases and crosswalk buttons (we acknowledge them in the design but do not implement).
• Multi-ambulance arbitration logic beyond simple first-come-first-served (noted as future work).

1. FR1 — RTOS Architecture: Both nodes shall use FreeRTOS with at least 4 concurrent tasks communicating via queues/event groups. (Course requirement.)
2. FR2 — Emergency Trigger: The ambulance unit shall broadcast a preemption request only while the physical Emergency switch is ON.
3. FR3 — GPS-Gated Transmission: Requests shall include the ambulance's GPS coordinates, heading, speed, and timestamp, and shall be sent at 2 Hz while within 1 km of a known intersection.
4. FR4 — Directional Relevance: The intersection unit shall only preempt for an approach whose bearing matches the ambulance's heading within ±45°.
5. FR5 — Safe Phase Transition: The controller shall never skip the yellow-to-red clearance; minimum-green, yellow, and all-red intervals are non-negotiable.
6. FR6 — Preemption Release: Green extension shall end when (a) the ambulance GPS indicates the intersection has been cleared, or (b) no valid packet is received for 2 s (timeout).
7. FR7 — Authentication: Packets shall carry an HMAC-SHA256 tag over a shared secret; packets failing verification are silently dropped.
8. FR8 — Replay Protection: Packets shall include a monotonically increasing sequence number; the intersection rejects sequence numbers it has already seen or that are more than 60 s old.
9. FR9 — Fail-Safe: On loss of power or firmware fault, all signal heads shall default to flashing red (fail-safe intersection per MUTCD).
10. FR10 — Manual Override: A button on the intersection unit shall force flashing-red regardless of preemption requests.
11. FR11 — Observability: Both units shall show live status on OLED, and every preemption event shall be logged (serial at minimum, SD card in stretch).

• MCU-centric: Two ESP32s. No Arduino used.
• Sensors / input: GPS module, IMU (optional stretch), Emergency switch, manual override button.
• Actuators / output: 12 LEDs driving a signal head, buzzer, OLED displays.
• RTOS: FreeRTOS (native on ESP-IDF) on both nodes — explicitly required by the instructor.
• Real-world problem: Ambulance response time in Cairo, documented and quantified.
• Non-trivial: Safe real-time phase control + authenticated wireless V2I + GPS geofencing + fail-safes.
• Realistic scope: Two nodes, ~4 weeks, based on available parts in the CSCE workshop plus local suppliers (RAM Electronics, Future Electronics Egypt, Makers Electronics).

1. GPS accuracy and cold-start time indoors — mitigated by testing outdoors and by stretch use of dead-reckoning.
2. LoRa duty-cycle and range inside the lab — mitigated by placing the intersection unit near a window, and by the ESP-NOW fallback.
3. Traffic state machine bugs causing unsafe transitions — mitigated by formalizing the FSM up front, unit-testing transitions, and hard-coding clearance intervals.
4. Integration slippage — mitigated by starting with the two subsystems running independently by M3, then integrating.

Figure 2. GreenWave system architecture. Two ESP32 nodes, each running FreeRTOS with four concurrent tasks, communicate over an authenticated LoRa 868 MHz link (HMAC-SHA256 signed packets, 2 Hz when emergency is active within a 1 km geofence). The optional cloud dispatch layer shown as a ghost element above is a stretch goal and is out of MVP scope.

Figure 3. Detailed hardware-software block diagram. Each node's FreeRTOS task set is shown explicitly, along with bus types (UART, I2C, SPI, GPIO), power rails, and the fail-safe behavior of the intersection node (all signals flash red on fault, power loss, or manual override).

                    ===========  AMBULANCE UNIT  ============
                    |                                        |
  +-----------+     |   +--------------------------------+   |
  | NEO-6M    |UART |   |                                |   |
  | GPS       |---->|-->|                                |   |
  +-----------+     |   |        ESP32 #1 (MCU)          |   |
  +-----------+     |   |       FreeRTOS Kernel          |   |  LoRa
  | Emergency |GPIO |   |                                |   |  868/915 MHz
  | Switch    |---->|-->|  Tasks:                        |SPI|==============>>
  +-----------+     |   |   - GpsTask                    |---|  (SX1276 TX)
  +-----------+ I2C |   |   - StateTask (emergency FSM)  |   |  HMAC-signed
  | OLED      |<----|---|   - PacketTask (LoRa TX)       |   |  preempt pkt
  | SSD1306   |     |   |   - DisplayTask                |   |  @ 2 Hz
  +-----------+     |   |   - WatchdogTask               |   |
  +-----------+ GPIO|   +--------------------------------+   |
  | Status LED|<----|                                        |
  +-----------+     |   Power: 5V USB / LiPo -> 3.3V LDO     |
                    ==========================================

                                        | wireless link
                                        v

                    ==========  INTERSECTION UNIT  ==========
                    |                                        |
                    |   +--------------------------------+   |  GPIO  +-----+
                    |   |                                |-->| R Y G |x4   |
         LoRa  SPI  |   |        ESP32 #2 (MCU)          |   | (12 LEDs: |
  >>===============>|-->|       FreeRTOS Kernel          |   |  N,S,E,W) |
         (SX1276 RX)|   |                                |   +-----------+
                    |   |  Tasks:                        |   |
                    |   |   - RxTask (LoRa + auth)       |GPIO|  +--------+
                    |   |   - ControllerTask (phase FSM) |--->|  | Buzzer |
                    |   |   - PreemptTask (arbitration)  |    |  +--------+
                    |   |   - DisplayTask (OLED)         |I2C |  +--------+
                    |   |   - WatchdogTask               |<-->|  | OLED   |
                    |   +--------------------------------+    |  +--------+
                    |                ^                        |  +--------+
                    |                | GPIO                   |  | Manual |
                    |                +------------------------|--| Overrd |
                    |                                         |  +--------+
                    |   Power: 5V USB wall adapter -> 3.3V    |
                    ===========================================
                                        ^
                                        |
                        Fail-safe: all signals flash red on
                        fault / power loss / manual override

Inputs: GPS (ambulance), emergency switch (ambulance), manual override button (intersection), LoRa packets (intersection side). Processing: FreeRTOS on both ESP32s. Ambulance FSM decides when to transmit. Intersection FSM runs the normal traffic cycle and arbitrates preemption. Outputs: 12-LED signal head, OLEDs on both units, buzzer, status LED on ambulance. Communication: LoRa SX1276 at 868/915 MHz (whichever is locally legal and available) as primary, ESP-NOW as fallback. Power: Separate 5V rails on each node; 3.3V derived by onboard LDO.

All three members share responsibility for integration testing, the proposal and progress presentations, and the final demo. Each member is expected to be able to explain the full system end to end.