G17: Smart Red Light Violation Detection System

Name	GitHub
Yousef Sayed	yousefsebaie
Marwan Abudaif	MarwanMoh11
Hadi Hesham	Hadihesham

GitHub Repo: https://github.com/MarwanMoh11/smart-redlight-tm4c123

1. The Proposal

Abstract

Running red lights is a leading cause of serious traffic accidents in Egypt and worldwide. Traffic officers cannot manually monitor every intersection around the clock, and without automated evidence capture, authorities have no reliable way to issue fines or deter repeat offenders. Simple motion-based detection systems can also mistake pedestrians or random movement for violating vehicles, creating false alarms.

Our project is the Smart Red Light Violation Detection System — an embedded real-time system that detects vehicles crossing a stop line during the red light phase, captures photographic evidence, and logs every violation with a timestamp to a PC. The system uses two Force-Sensitive Resistors (FSRs) placed in sequence at the stop line: one for the front axle and one for the rear axle. A real vehicle should press the first pressure sensor and then the second pressure sensor within a calibrated time window. This front-then-rear sequence allows the firmware to distinguish a vehicle from a pedestrian, because a pedestrian or random touch usually presses only one sensor or does not produce the correct axle sequence.

The firmware runs on a TI Tiva C TM4C123GXL Launchpad using FreeRTOS with six concurrent tasks: sensor detection, violation logic, traffic light cycle, alert, camera capture, and UART logging. When a valid vehicle event occurs during the red phase, the violation event is sent to three independent handlers: an alert handler that flashes the onboard RGB LED, a camera handler that triggers photo capture, and a logging handler that writes a timestamped record to the PC terminal. This system demonstrates a practical embedded application of multitasking, queues, priority scheduling, shared state, ADC sensing, and event-driven violation handling.

Project Objectives & Scope

Minimum Viable Product (MVP)

• Automatic traffic light cycle: GREEN → YELLOW → RED
• Detection active only during the RED light phase
• Dual-FSR pressure-sensor vehicle detection at the stop line
• Front-axle and rear-axle sequence detection
• Pedestrian and false-trigger filtering using axle order and timing window
• Full FreeRTOS architecture with 6 concurrent tasks
• Inter-task communication using queues, task priorities, shared state, and UART synchronization
• Fan-out dispatch: each confirmed violation triggers alert, camera, and log handlers
• Visual alert on confirmed violation using the onboard RGB LED
• Photo capture of the violating vehicle using a laptop webcam
• UART event logging to PC terminal with timestamps

Stretch Goals

• 16x2 LCD display showing current light state and violation count
• Manual override buttons: force red light and reset counter
• Persistent violation count stored in flash memory
• Emergency vehicle exemption mode
• Multi-lane support by replicating the hardware unit per lane
• Dedicated external flash LED synchronized with camera capture

2. System Architecture

2.1 High-Level Block Diagram

2.2 Subsystem Breakdown

Subsystem	Description
Sensor subsystem	Two FSR pressure sensors are the primary vehicle detector. FSR_A is connected to PE3 / ADC0 CH0 and represents the front axle sensor. FSR_B is connected to PE2 / ADC0 CH1 and represents the rear axle sensor. Both sensors are read through the ADC and polled periodically. The firmware confirms a vehicle only when the correct FSR sequence occurs within a calibrated timing window. The HC-SR04 ultrasonic sensor on PB0/PB1 is kept as a secondary approach indicator only and does not directly trigger violations.
Traffic light subsystem	LightTask drives the onboard RGB LED. GREEN is PF3, RED is PF1, and YELLOW is produced using PF1 + PF3. The light state is stored in the shared volatile variable g_current_light, which is read by ViolationTask.
Violation logic subsystem	ViolationTask receives vehicle-detection events from the sensor queue. It checks whether g_current_light == LIGHT_RED. If the light is not red, the event is ignored. If the light is red, the task builds a violation_record_t and sends it to the alert, camera, and log queues.
Alert subsystem	AlertTask receives violation records and produces a visual flicker on the onboard RGB LED. This provides immediate visible feedback when a violation is detected.
Camera subsystem	CameraTask receives violation records and triggers photo capture of the violating vehicle. The original ESP32-CAM was replaced by a laptop webcam after firmware issues.
Logging subsystem	LogTask receives violation records and writes timestamped messages to UART0 at 115200 baud. UART access is protected so that different tasks do not interleave their output. Logs are viewed on the PC using picocom.

3. Hardware Design

3.1 Component Selection

Component	Purpose	Notes
TI Tiva C TM4C123GXL Launchpad	Main MCU	ARM Cortex-M4F, 80 MHz, 256 KB Flash, 32 KB SRAM. Runs FreeRTOS and all six tasks.
2x Force-Sensitive Resistors	Primary vehicle detection	Used as front and rear axle pressure sensors. FSR_A is connected to PE3 / ADC0 CH0, and FSR_B is connected to PE2 / ADC0 CH1.
HC-SR04 Ultrasonic Sensor	Secondary approach indicator	TRIG on PB0 and ECHO on PB1. Used only as an approach indicator, not as the primary violation trigger.
ESP32-CAM	Photograph capture	PD7,FTDI
Onboard RGB LED	Traffic light simulation and violation alert	PF1 for red, PF3 for green, and PF1 + PF3 for yellow.
Breadboard + jumper wires	Prototyping	Used for wiring and testing.
USB to PC	Power, flashing, and UART logging	Provides board power and PC serial communication.

3.2 Schematics & Wiring

FSR Pressure Sensors to TM4C123GXL

Each FSR is wired as a voltage divider. The midpoint of the divider is connected to an ADC input pin so the TM4C123GXL can read the pressure level as an analog value.

FSR Sensor	Tiva Pin	ADC Channel	Role
FSR_A	PE3	ADC0 CH0	Front axle sensor
FSR_B	PE2	ADC0 CH1	Rear axle sensor

HC-SR04 to TM4C123GXL

HC-SR04 Pin	Tiva Silkscreen	Port/Pin
VCC	+3.3V	—
TRIG	PB0	GPIO_PORTB_BASE, GPIO_PIN_0
ECHO	PB1	GPIO_PORTB_BASE, GPIO_PIN_1
GND	GND	—

Important: The HC-SR04 is powered from 3.3V instead of 5V so that the ECHO signal remains safe for the TM4C123GXL input pin.

Onboard RGB LED

Color	Pin	FreeRTOS State
Red	PF1	LIGHT_RED
Blue	PF2	Unused in traffic cycle
Green	PF3	LIGHT_GREEN
Yellow	PF1 + PF3	LIGHT_YELLOW

Camera and UART Outputs

Signal	Port/Connection	Purpose
Camera trigger	Laptop webcam / host-side capture	Captures image on violation event
Debug UART TX	PA1 / U0TX	UART logging at 115200 baud
Debug UART RX	PA0 / U0RX	Serial receive line if needed

Manual Override Buttons

Button	Pin	Function
SW1	PF4	Force RED phase
SW2	PF0	Reset violation counter

3.3 Bill of Materials

Component	Qty	Estimated Cost
TI Tiva C TM4C123GXL Launchpad	1	~2000 EGP
Force-Sensitive Resistors	2	~1000 EGP
HC-SR04 Ultrasonic Sensor	1	~60 EGP
Esp32-CAM	1	~900 EGP
Breadboard + jumper wires	1 set	~20 EGP
USB cable	1	Existing / reused
Total		~4000 EGP

3.4 Power Budget

Component	Supply	Typical Current	Peak Current
TM4C123GXL MCU	3.3V	~30 mA	~50 mA
FSR voltage dividers x2	3.3V	<1 mA	<1 mA
HC-SR04	3.3V	~15 mA	~15 mA
Onboard RGB LED	3.3V	~3 mA	~3 mA
ESP32_Cam	5v	drawn from board	drawn from board
3.3V rail total		~49 mA	~69 mA

The Launchpad onboard regulator supplies enough current for the MCU, pressure sensors, ultrasonic approach sensor, and onboard LED. The laptop webcam is powered by the host PC and does not draw power from the Launchpad.

4. Software Implementation

4.1 Software Architecture

The firmware is implemented as a FreeRTOS preemptive multitasking application targeting the TM4C123GXL at 80 MHz. The clock is configured using SysCtlClockSet with the PLL from a 16 MHz crystal. The FreeRTOS tick rate is 1 ms using configTICK_RATE_HZ = 1000, which gives millisecond-level timing for task delays, timestamps, and sensor timing windows.

Six tasks are created in main() before calling vTaskStartScheduler().

Task	Stack	Priority	Responsibility
ViolationTask	256 words	4	Blocks on the sensor queue, checks whether the light is red, builds a violation record, and sends it to the alert, camera, and log queues.
LightTask	256 words	3	Cycles GREEN → YELLOW → RED and updates g_current_light.
AlertTask	256 words	3	Blocks on xAlertQueue and produces a visible LED flicker.
CameraTask	256 words	2	Blocks on xCameraQueue and triggers photo capture.
LogTask	512 words	2	Blocks on xLogQueue and writes timestamped violation records to UART0.
SensorTask	512 words	1	Polls the two FSR pressure sensors, runs the axle-detection state machine, and posts SENSOR_VEHICLE_DETECTED to xSensorEventQueue. It also polls the HC-SR04 approach indicator.

ViolationTask has the highest priority because it should react immediately once a valid vehicle event is posted. SensorTask runs at the lowest priority because it polls periodically and uses vTaskDelay, so it does not starve the other tasks.

4.2 Inter-Task Communication

Queue / Shared Object	Item Type	Depth	Producer → Consumer
xSensorEventQueue	sensor_event_t	8	SensorTask → ViolationTask
xAlertQueue	violation_record_t	4	ViolationTask → AlertTask
xCameraQueue	violation_record_t	4	ViolationTask → CameraTask
xLogQueue	violation_record_t	16	ViolationTask → LogTask
g_current_light	light_state_t	—	LightTask → ViolationTask
xUartMutex	Mutex	—	Protects UART output

g_current_light is a volatile shared variable. It has one writer, LightTask, and one reader, ViolationTask. Since it is a simple light-state value on a 32-bit MCU, a mutex is not required for this variable. UART output is protected separately using xUartMutex.

4.3 Flowcharts & State Machines

Overall System Data Flow

flowchart LR
    A[FSR_A Front Axle Sensor] -->|ADC value| B[SensorTask]
    A2[FSR_B Rear Axle Sensor] -->|ADC value| B
    U[HC-SR04 Approach Indicator] -->|distance only| B
    B -->|SENSOR_VEHICLE_DETECTED| C[ViolationTask]
    L[LightTask] -->|g_current_light| C
    C -->|if RED| D[AlertTask]
    C -->|if RED| E[CameraTask]
    C -->|if RED| F[LogTask]
    D -->|visual flicker| G[Onboard RGB LED]
    E -->|capture request| H[Laptop Webcam]
    F -->|UART 115200 baud| I[PC Terminal]
    L -->|traffic light state| G

Traffic Light State Machine

stateDiagram-v2
    [*] --> GREEN
    GREEN --> YELLOW: after 6000 ms
    YELLOW --> RED: after 2000 ms
    RED --> GREEN: after 5000 ms

Dual-FSR Axle Detection State Machine

stateDiagram-v2
    [*] --> S_IDLE
    S_IDLE --> S_A_HIT: FSR_A pressed first
    S_IDLE --> S_LOCKED: both sensors pressed together
    S_A_HIT --> S_LOCKED: FSR_B pressed within valid gap
    S_A_HIT --> S_LOCKED: timeout, invalid object
    S_A_HIT --> S_IDLE: FSR_A released without FSR_B
    S_LOCKED --> S_IDLE: both sensors released

Violation Logic Flow

flowchart TD
    A[Wait for sensor event] --> B{Vehicle detected?}
    B -->|No| A
    B -->|Yes| C{Is light RED?}
    C -->|No| D[Discard as legal pass]
    D --> A
    C -->|Yes| E[Build violation_record_t]
    E --> F[Send to Alert Queue]
    E --> G[Send to Camera Queue]
    E --> H[Send to Log Queue]
    F --> A
    G --> A
    H --> A

4.4 Key Algorithms

Reading the FSR Pressure Sensors

The two FSRs share one ADC sequencer and are read together in a single conversion. The sensor task triggers the ADC, waits for conversion completion, and reads both ADC channels into a buffer. Channel 0 corresponds to FSR_A, and channel 1 corresponds to FSR_B.

A higher ADC count means a stronger press on the pressure sensor. The firmware uses these ADC values to determine whether each pressure sensor is currently pressed or released.

Threshold Calibration and Hysteresis

The FSR thresholds were calibrated empirically by comparing idle readings with pressed readings. When there is no pressure, the ADC value is low. When the sensor is pressed firmly, the ADC value becomes much higher. Based on this behavior, the firmware uses a high press threshold and a lower release threshold.

#define FSR_PRESS_THRESHOLD     1000
#define FSR_RELEASE_THRESHOLD   200

This creates hysteresis. The sensor is considered pressed only when the reading goes above 1000, but it is not considered released until the reading drops below 200. This prevents flickering when the ADC value is noisy or close to the threshold boundary.

Dual-FSR Axle Detection

The pedestrian filter is implemented through the front-axle and rear-axle sequence. A real vehicle should press FSR_A first and then FSR_B within a calibrated time window.

#define FSR_AB_GAP_MS_MIN   50
#define FSR_AB_GAP_MS_MAX   3000
#define FSR_POLL_PERIOD_MS  50

The logic works as follows:

• In S_IDLE, the system waits for a valid first press.
• If FSR_A is pressed first, the system records the tick time and moves to S_A_HIT.
• If FSR_B is pressed after FSR_A within the valid timing window, the system confirms a vehicle.
• If the time exceeds the maximum gap, the event is ignored.
• If FSR_A is released before FSR_B is pressed, the event is ignored.
• After a confirmed or invalid event, the system enters S_LOCKED until both sensors are released, preventing double counting.

This is how the system filters pedestrians and random false triggers. A pedestrian or accidental touch usually does not create the correct two-sensor axle sequence.

HC-SR04 Approach Indicator

The HC-SR04 is kept as a secondary approach indicator. It does not directly create violation events. It only helps indicate when an object is near the stop line.

The ultrasonic sensor is triggered using a short HIGH pulse on PB0. The firmware measures the ECHO pulse width on PB1 and converts it to a distance reading. Invalid readings are treated as out of range.

Fan-Out Dispatch

ViolationTask uses non-blocking queue sends to dispatch one confirmed violation record to three independent consumers:

• xAlertQueue
• xCameraQueue
• xLogQueue

This means the alert, camera, and logging functions are separated. If one downstream task is slow, the violation logic is not directly tied to it.

5. Development Environment

Tool	Details
Toolchain	gcc-arm-none-eabi
Linker / Assembler	binutils-arm-none-eabi
C Library	libnewlib-arm-none-eabi
Build system	GNU Make
FreeRTOS Kernel	V11.1.0
TivaWare DriverLib	SW-TM4C-2.2.0.295
Flasher	lm4flash
Serial monitor	picocom -b 115200 /dev/ttyACM0
OS	Ubuntu 22.04 / Linux Mint 21
IDE	Text editor + terminal

Build and Flash Commands

git clone https://github.com/MarwanMoh11/smart-redlight-tm4c123.git
cd smart-redlight-tm4c123
make
make flash
picocom -b 115200 /dev/ttyACM0

Example Successful Build Output

   text    data     bss     dec     hex filename
  11000       8   21800   32808    8028 build/redlight.elf

6. Testing, Validation & Debugging

6.1 Unit Testing

Module	Test Method	Pass Criterion
FSR_ReadBoth()	Read raw ADC values with no press, light press, and firm press.	Idle readings stay low; firm press rises clearly above the press threshold.
Threshold / hysteresis	Pressed and slowly released each FSR.	Clean press above 1000 and release below 200, without unstable flickering.
Axle state machine	Pressed FSR_A then FSR_B at different gaps.	Vehicle event only when both sensors are pressed in the correct order within the valid window.
Wrong-order rejection	Pressed FSR_B before FSR_A.	No vehicle event is generated.
Single-sensor rejection	Pressed only one FSR.	No vehicle event is generated.
LightTask timing	Measured phase durations using UART phase-start markers.	GREEN about 6 seconds, YELLOW about 2 seconds, RED about 5 seconds.
ViolationTask dispatch	Injected SENSOR_VEHICLE_DETECTED while forcing RED state.	Alert, camera, and log handlers all receive the violation.
LogTask output	Checked UART format and incrementing counter.	Correct violation message printed with violation number and tick timestamp.

6.2 Integration Testing

Phase	Action	Expected Result
GREEN	Press FSR_A then FSR_B in sequence.	No violation. Legal pass is ignored.
YELLOW	Press FSR_A then FSR_B in sequence.	No violation. Legal pass is ignored.
RED	Press only one FSR.	No violation. Pedestrian / false trigger rejected.
RED	Press FSR_B before FSR_A.	No violation. Wrong axle order rejected.
RED	Press FSR_A then FSR_B within the valid gap window.	Violation confirmed: LED flicker, UART log, and camera capture.
RED repeated	Two back-to-back valid A→B sequences.	Two separate records are generated after proper re-arm.

6.3 UART Output for a Successful Violation

=== Smart Red Light System Online ===
Press FSR_A then FSR_B during RED phase to trigger violation.

--- GREEN ---
--- YELLOW ---
--- RED (detection active) ---
    [APPROACH] object near stop line
>>> VIOLATION #1 at tick=12345 (light=RED)
    [CAMERA] capture_request tick=12345 -> img_12345.jpg
--- GREEN ---

6.4 Challenges & Solutions

Challenge	Root Cause	Solution
Boot loop or banner repeating	Stack overflow in SensorTask.	Increased SensorTask stack from 256 to 512 words.
LED stuck on GREEN	Sensor polling was too aggressive and could starve other tasks.	Added periodic vTaskDelay and kept sensor polling at a fixed rate.
Double violation events	One vehicle could be counted more than once.	Added the S_LOCKED state so the system re-arms only after both FSRs are released.
UART garbled output	More than one task could write to UART at the same time.	Protected UART output using xUartMutex.
FSR readings unstable near threshold	ADC readings fluctuated near the boundary.	Added hysteresis using a high press threshold and a lower release threshold.
HC-SR04 always reads 0 cm	TRIG and ECHO pins were swapped on the breadboard.	Verified wiring against silkscreen and added a startup pin-configuration check.
ESP32-CAM	The module entered a burnout cycle and stopped working.	Managed to work.
make flash permission denied	User did not have serial-device permissions.	Added user to dialout and plugdev, installed udev rules, and logged in again.

7. Results & Demonstration

7.1 Final Prototype

The current build runs fully on the TM4C123GXL Launchpad. The two FSR pressure sensors are connected to PE3 and PE2 and act as the primary vehicle detector. The HC-SR04 is connected to PB0 and PB1 and acts only as a secondary approach indicator. The onboard RGB LED acts as both the traffic light and the visual violation alert. All six FreeRTOS tasks are active and communicate through queues. Photo capture is handled by a laptop webcam triggered on each violation event, and UART output is viewed in real time through picocom at 115200 baud.

Photos of the completed breadboard setup should be added after the final demo build.

7.2 Video Demonstration

Demo video link should be added before the final presentation.

7.3 Performance Metrics

Metric	Target	Measured
FSR poll rate	20 Hz / 50 ms period	20 Hz verified by UART timing
Traffic light phase accuracy	±100 ms	±50 ms
Violation detection latency	Less than 100 ms after rear axle press	About 50 ms
Pedestrian false positive rate	0% for single-sensor presses	0% across single-FSR tests
Wrong-order rejection	0% false positives	FSR_B before FSR_A always rejected
Missed violations	0% for valid A→B passes	10 out of 10 valid passes detected
UART log latency	Less than one scheduler cycle	Less than 2 ms

8. Project Management

8.1 Division of Labor

Team Member	Primary Responsibilities
Yousef Sayed	Hardware wiring, FSR sensor interfacing, sensor task implementation, axle-detection and pedestrian-filter firmware, violation logic.
Marwan Abudaif	Camera integration, traffic light task, timing cycle, system integration,build system, and ADC threshold calibration.
Hadi Hesham	UART logging task, PC terminal protocol, alert task, wiki documentation, proposal, final presentation, and integration testing.

All team members collaborated on:

• System integration and debugging
• Edge-case testing
• Pedestrian-filter validation
• Partial-crossing and timeout handling
• Demo preparation and rehearsal
• Final presentation delivery

8.2 Timeline

Date	Milestone	Status
Apr 15	Proposal presentation	Complete
Apr 20	Wiki page live / Checkpoint A	Complete
Apr 20 – Apr 28	Core firmware: sensor reading, traffic light cycle, and state machine	Complete
Apr 29	Progress demo: live violation detection working	Complete
Apr 30 – May 5	Full integration: FSR sensors, camera capture, alert, and UART logging	Complete
May 6	Integration update / Checkpoint B	Complete
May 7 – May 12	Bug fixes, threshold tuning, edge-case testing, and demo rehearsal	In progress
May 13	Final demo and presentation	Pending

9. Appendices & References

9.1 Source Code Repository

https://github.com/MarwanMoh11/smart-redlight-tm4c123

9.2 References

1. Texas Instruments, TM4C123GH6PM Datasheet, SPMS376E.
   https://www.ti.com/product/TM4C123GH6PM

2. Texas Instruments, TivaWare Peripheral Driver Library User's Guide, SPMU298D.

3. FreeRTOS, FreeRTOS Documentation and Reference Manual.
   https://www.freertos.org/Documentation/RTOS_book.html

4. Elec Freaks, HC-SR04 Ultrasonic Sensor Datasheet.

5. Interlink Electronics, FSR Integration Guide.
   https://www.interlinkelectronics.com/fsr-402

9.3 Slides

Slides: https://docs.google.com/presentation/d/1CavqB2eSc4E3dqD2mCK92nwCfTT1sVUNiy0WjSi58_Y/edit?slide=id.p4#slide=id.p4