Sixteen cameras in one exam hall: the architecture of ExamShield

Exam proctoring software has a bad reputation, most of it earned. Systems that flag a student for looking away, that stream video to a vendor, that treat suspicion as a score to be maximised. I built ExamShield to see whether the useful part could be kept while the harmful parts were designed out.

The useful part is narrow: detecting a phone on a desk in a hall of a hundred students is genuinely hard for a human invigilator and genuinely easy for a camera. The harmful part is everything that follows from treating detection as accusation.

The pipeline

Frames arrive from up to sixteen cameras. Capture runs on its own thread per camera so that inference latency never stalls acquisition, which is the difference between a system that degrades and one that drops frames silently.

YOLOv8 handles object detection: phones, earphones, smartwatches, with per class confidence thresholds rather than one global number, because a phone and a smartwatch do not deserve the same evidentiary weight.

Above detection sits the part I care about more. Centroid based tracking keeps a stable identity for each student across frames, so behaviour is attributed to a person rather than to a bounding box that reappears each frame. On top of that, sustained head rotation over a five second window and paper passing between adjacent students are evaluated as behaviour, not as instants.

Fusing a second sense

Cameras cannot see a phone in a pocket. ESP32 microcontrollers around the room run a BLE scanner and a WiFi sniffer, streaming over UDP and TCP respectively, so a device that never becomes visible can still register as present.

Two independent senses matter because they fail differently. Vision fails on occlusion. Radio fails on shielding and noise. A signal both agree on is worth far more than either alone.

Designed against false positives

The scoring is priority weighted, and alerts pass through a cooldown so that one event cannot fire repeatedly and drown the invigilator in noise. This is the design decision I would defend hardest: an alert system that cries wolf is worse than no alert system, because it trains its operator to ignore it.

Every alert carries evidence, a captured frame and a CSV session record, so a human reviews a specific moment rather than a verdict.

Running at the edge

The whole thing targets Raspberry Pi nodes with CUDA or DirectML acceleration where available and CPU fallback where not. That is a deliberate constraint. Footage of students should not leave the building, and a system that requires a cloud round trip per frame cannot make that promise.

Where the research question sits

The engineering works. The open questions are the interesting ones: how to coordinate identity across overlapping camera views, how to quantify false positive cost against missed detection cost when the harm is asymmetric, and how to make an alert interpretable enough that an invigilator can disagree with it.

Source: ExamShield