Skip to content
RoadGuard AI
Live Demo

Technical report

How it works, and what we don't know yet

The design is settled; several measurements are not. Anything not yet measured is listed as an open item rather than filled in with a number that would read well — there are 20 of them on this page.

01

Problem

Given an MP4 from a fixed road camera, produce a list of traffic events as time segments — a start second, an end second and one of 14 class labels — and, separately, a per-frame score between 0 and 1 for the probability that an accident begins within the next 5 seconds.

The two outputs are scored independently, and they pull in different directions. Event detection rewards precise boundaries on things that have already happened. Anticipation rewards a causal signal that rises before anything has happened at all. Treating them as one problem produces a system that is late on both.

02

Data

The organiser sample clips from a single fixed camera, plus the annotations released with them. Because every clip comes from the same viewpoint, scene geometry can be calibrated once and treated as known for all of them.

Class balance is the dominant property of this data: ordinary violations are common, collisions are rare, and fire or smoke may not appear at all. Any metric that averages over classes has to be read with that in mind.

Open items

  • Record the exact clip count, total duration and per-class annotation counts once the final data pull is fixed.
  • State which clips were used for development and which were held out, and confirm no held-out clip informed a threshold.

03

Exploratory analysis

Trajectories collapse onto two carriageway corridors plus a pedestrian crossing; motion density concentrates in a small fraction of the frame. Both findings argue for spending effort on scene calibration rather than on generic whole-frame modelling.

Lighting varies across the sample set from midday to night. The night clip carries noticeably fewer tracks at a comparable apparent density, which is the signature of a detector dropping small, poorly-lit road users rather than of a quieter road.

The full analysis, with the decision each chart led to, is on the EDA page of this site.

04

System architecture

Decode at a fixed stride, detect road users, track them into trajectories. After tracking the pipeline forks: one branch applies scene geometry and traffic rules to produce event segments, the other computes interaction features between track pairs to produce the risk curve.

The fork matters for debugging. A missed event and an under-confident risk curve have different causes and are fixed in different places, and keeping the branches separate keeps that distinction visible.

05

Object detection

A single-stage detector proposes boxes for six classes: car, truck, bus, motorcycle, bicycle and pedestrian. Input resolution is chosen by the smallest pedestrian that has to survive, which in practice is set by the night clip rather than by any daytime footage.

Open items

  • Name the detector architecture and weights actually shipped, and whether they were fine-tuned or used as released.
  • Record input resolution, confidence threshold and NMS settings.

06

Tracking

Detections are associated across frames so each road user keeps one identity for as long as it is visible. Short occlusions are bridged rather than allowed to split a track, because a split track breaks every rule that reads trajectory history.

Identity stability, not raw detection accuracy, is the property most rules actually depend on.

Open items

  • Name the tracker and its association parameters.
  • Report identity switches per clip, the number that predicts rule failures best.

07

Scene geometry

The road polygon, lane polygons with expected directions, stop lines, crosswalk, intersection box, solid markings and the signal region are calibrated once for the camera and reused across clips.

This is the cheapest accuracy available in the whole system. It converts several classes from open vision problems into geometry tests, and it makes failures inspectable: a wrong-way false positive usually means a lane vector is wrong, not that a model is confused.

Open items

  • Replace the placeholder calibration in config/scene.ts with the measured one, and state the tool it was produced with.

08

Event detection rules

Where the traffic code has a crisp definition, the definition is encoded rather than learned: wrong-way driving as a sustained heading opposite the lane vector, stopped vehicle as displacement under a threshold for at least ten seconds inside the road polygon, jaywalking as a pedestrian centroid inside the road and outside every crossing, solid-line crossing as a trajectory intersecting a calibrated line.

Rules are deterministic, cheap and inspectable, and each one names the geometry it depends on. That is what makes a false positive traceable to a specific polygon.

Open items

  • Publish the final threshold table — durations, distances and hysteresis margins — and how each value was chosen.

09

Accident and near-miss logic

Collisions and near misses resist a clean geometric definition, so they are decided from interaction features over track pairs: relative motion, path intersection, time-to-collision, and the deceleration and heading changes around the moment of conflict.

The distinction between the two classes is what happens after the conflict. A near miss is a low time-to-collision where both tracks survive and never overlap; a collision is where they do.

Open items

  • State whether the interaction model is learned or threshold-based in the shipped system, and what it was fitted on.

10

Accident anticipation

The risk head answers one question per frame: what is the probability that an accident starts within the next 5 seconds. It is causal by construction — it may only read frames up to the current one.

Time-to-collision is the strongest available signal, but it over-fires in dense traffic where everything is already slowing. Deceleration, heading change, lane context and local density are combined with it so that ordinary congestion does not read as imminent collision.

The property to check is lead time, not peak height: a curve that spikes after impact has detected a crash rather than anticipated one, and would be worthless in operation even if it scored well.

Open items

  • Report measured lead time — how far ahead of annotated impacts the curve crosses the alarm threshold.
  • Report the false-alarm rate on clips with no collision, which is what determines whether an operator would keep the alarm switched on.

11

Temporal post-processing

Per-frame decisions are noisy, and the evaluation reads segments. Fragments of one class are merged across short gaps, segments below a minimum duration are dropped, boundaries are snapped to where evidence actually begins and ends, and two segments of the same class are never allowed to overlap.

This stage changes scores more than most model choices do, because it is what converts a correct-but-flickering signal into a segment that matches an annotation.

Open items

  • Record the merge gap and minimum-duration values per class, and the score change each contributed.

12

Experiments

The ablation table below is the intended experimental frame: measure the contribution of tracking, scene rules and temporal smoothing separately, so the score can be attributed rather than guessed at.

Open items

  • Run each ablation and fill in content/ablations.ts. Rows without measurements render as pending and are never presented as results.

Ablations

What each stage is worth. The plan is fixed; the numbers arrive with the evaluation run.

No ablation has been run yet. Rows below describe the planned configurations — none of them carries a score.

ConfigurationAddsScore AScore BRuntime
Detector onlyPer-frame boxes, no identity and no history.not measurednot measurednot measured
+ TrackingPersistent IDs, which makes trajectory-based rules possible at all.not measurednot measurednot measured
+ Scene rulesCalibrated lanes, stop lines and crossings driving the rule engine.not measurednot measurednot measured
+ Temporal smoothingFragment merging, noise removal and boundary refinement.not measurednot measurednot measured
+ Conflict features for riskDeceleration, heading change and density gating on top of time-to-collision.not measurednot measurednot measured

Headline metrics

Filled in from the official evaluation, and from nowhere else.

Score A
not measured
Event-detection score from the official metric.
Score B
not measured
Accident-anticipation score from the official metric.
Throughput
not measured
Frames per second on the evaluation machine.
Runtime ratio
not measured
Wall-clock processing time divided by clip duration.

13

Runtime and optimisation

Inference runs offline on the evaluation machine with no hosted AI service. Frame stride is the main runtime control: detection dominates cost, and the stride sets how often it runs.

No real-time claim is made anywhere on this site, because no runtime measurement has been taken yet.

Open items

  • Measure throughput in FPS and the ratio of processing time to clip duration, on the stated hardware.
  • State the hardware the measurement was taken on.

14

Failure cases

The categories below are the ones this design is structurally vulnerable to, listed before measurement rather than after, so they can be checked rather than rationalised.

Limitations

Where the system struggles

Showing the edges of a system is part of engineering it. These are the failure modes this design is structurally exposed to, written down before measurement so they can be tested rather than explained away.

None of these has been confirmed in output yet, so every card is marked predicted. As real examples are found, each will carry the clip and timestamp it was observed in.

  • predicted

    Heavy occlusion

    A vehicle hidden behind a bus loses its track, and a track that restarts with a new identity breaks every rule that reads history.

    Hits these classes first

    Near missCollisionStopped vehicle

    What we do about it

    Bridge short occlusions in the tracker rather than starting a new identity, and require rules to tolerate a gap.

  • predicted

    Dense traffic

    Time-to-collision is low for everyone in slow, packed traffic, so a naive risk head reads a jam as a stream of imminent collisions.

    Hits these classes first

    Near missCongestion

    What we do about it

    Gate time-to-collision with deceleration and local density, so risk only rises when something is behaving unusually for the conditions.

  • predicted

    Small distant pedestrians

    Pedestrians far from the camera occupy a handful of pixels. Miss them and jaywalking and failure-to-yield never fire at all.

    Hits these classes first

    Pedestrian on roadwayNot yielding to pedestrian

    What we do about it

    Set input resolution by the smallest pedestrian that must survive, not by the fastest configuration that runs.

  • predicted

    Poor lighting

    At night, contrast collapses and headlights bloom. Recall drops for every class, and drops most for the classes that were already small.

    Hits these classes first

    Pedestrian on roadwayObstacle on roadCollision

    What we do about it

    Keep a night clip in the development set so the failure is visible during tuning rather than at evaluation.

  • predicted

    Ambiguous signal colour

    Reading light colour from a fixed region fails on glare, a partly occluded head, or a lamp that saturates the sensor — and red-light detection depends entirely on it.

    Hits these classes first

    Red-light runningStop-line violation

    What we do about it

    Prefer temporal consistency over per-frame colour, and decline to fire rather than guess when the region is unreadable.

  • predicted

    Vehicles entering and leaving frame

    A manoeuvre that starts off-camera has no history. Boundary timestamps at the edges of the clip are systematically unreliable.

    Hits these classes first

    Illegal turnWrong-way drivingIllegal U-turn

    What we do about it

    Require a minimum observed history before a rule may fire, and accept the recall cost at the frame edges.

  • predicted

    Unusual manoeuvres

    Three-point turns, reversing and service vehicles working in a lane look like violations to rules written for ordinary traffic.

    Hits these classes first

    Illegal U-turnWrong-way drivingStopped vehicle

    What we do about it

    Keep rules narrow and let the class stay unfired, rather than widening a rule until it catches legitimate behaviour.

  • predicted

    Partially visible collisions

    If the impact itself happens behind an obstruction, the only evidence is the aftermath — which arrives too late for anticipation to be scored well.

    Hits these classes first

    CollisionNear miss

    What we do about it

    Weight pre-impact conflict features rather than post-impact appearance, so the signal does not depend on seeing contact.

15

What worked

Calibrating the scene once and treating geometry as known — it removed whole classes of ambiguity and made rule failures traceable.

Keeping detection of events and anticipation of accidents as separate branches over shared tracking, instead of one model asked to do both.

Building the visualisation before tuning thresholds. Seeing a risk curve next to its clip makes a bad threshold obvious in seconds, where a metric only says the number moved.

16

What did not work

Open items

  • Record the approaches that were tried and dropped, with the reason each was dropped. This section is deliberately empty rather than filled with plausible-sounding failures.

17

What we would build next

Multi-camera calibration, so the same geometry approach extends to a network rather than one view.

Explicit signal-state estimation rather than reading colour from a fixed region, which is the most fragile input in the current design.

An operator feedback loop: let a human confirm or dismiss an alarm, and use those decisions to retune thresholds per camera.

18

External models and datasets

Any pretrained weights, external datasets and third-party libraries used are listed here with their licences, so the submission can be reproduced and audited.

Open items

  • List every pretrained checkpoint and dataset with source and licence.
  • Confirm each licence permits the use made of it in this submission.

19

Reproducibility

The intended path is: clone the repository, install pinned dependencies, download weights, run inference on a clip, and get the same predictions file that produced the results on this site.

Open items

  • Publish the repository, the weights and predictions_samples.json, then fill in config/site.ts so the links on this site go live.
  • Pin random seeds and dependency versions, and state the hardware the results were produced on.

Artefacts

Everything the submission publishes outside this site. Links go live as each artefact is released.

Published artefacts

An entry without a URL is shown as unavailable rather than linked somewhere that does not exist.

  • Repository

    Training code, inference service and this website.

    not published yet
  • Model weights

    Detector and interaction-model checkpoints.

    not published yet
  • predictions_samples.json

    Raw event predictions for the organiser sample clips.

    not published yet
  • Technical report

    The written submission, also readable on this site.

    not published yet