Multi-Object Tracking with Global Nearest Neighbour Association

The problem

Once several vehicles, two-wheelers and roadside clutter are in view, a tracker has to decide which detection belongs to which object at every scan. Wrong decisions create track swaps, broken tracks and ghost objects, which in turn cause wrong ACC targets and false braking. Global nearest neighbour is the most widely used practical association method in automotive tracking, and a careful study shows exactly where it works and where it breaks.

Objectives

• Build multi-target scenarios with crossing, merging and closely spaced vehicles.
• Implement gating and global nearest neighbour association with an assignment solver.
• Design track confirmation and deletion logic and tune its parameters.
• Evaluate with GOSPA, track swaps, track breaks and false tracks.
• Compare GNN with greedy nearest-neighbour association across clutter and detection-probability levels.

What you need

Key concepts

Gating

Only detections whose statistical distance from a track's prediction is below a threshold are considered for that track. It keeps the assignment problem small and rejects implausible pairings.

Global nearest neighbour

Assignment of detections to tracks that minimises the total cost over all pairs at once, with each detection used at most once. It avoids the greedy mistake of giving a detection to the first track that wants it.

M-of-N track management

A tentative track is confirmed after M hits in N scans and deleted after a run of misses. These numbers trade quick confirmation against false tracks.

GOSPA metric

Generalised optimal sub-pattern assignment combines localisation error, missed targets and false tracks into one number per time step, so trackers can be compared fairly.

Step-by-step guide

1. 1

   Define requirements and scenarios

   State the tracking task: up to 15 objects within 150 m ahead and 20 m to each side, at a 20 Hz sensor rate. Set target figures for track swaps, false tracks per minute and position error. Plan scenarios that stress association: dense highway traffic, two vehicles overtaking side by side, a merge with closely spaced cars, an urban junction with crossing traffic and parked cars near the lane edge creating clutter.

   Checkpoint: A scenario list with the association difficulty each one creates and the numerical targets.

2. 2

   Build the scenarios and sensor

   Create the scenarios with drivingScenario, using actor trajectories from waypoints and realistic speeds. Mount a drivingRadarDataGenerator with clutter enabled and set detection probability, false alarm rate and resolution to plausible values. Script versions with detection probability from 0.7 to 0.95 and clutter levels from low to high. Fix random seeds so every tracker sees identical detections. Include at least one scenario with a motorcycle-sized actor between cars, which is common on Indian roads and tests resolution.

   Checkpoint: Bird's-eye plots of each scenario showing ground truth and the clutter-laden detections.

3. 3

   Implement gating and assignment from scratch

   In Python or MATLAB, write a small tracker with one constant-velocity Kalman filter per track. Build the cost matrix of Mahalanobis distances between predicted tracks and detections, set gated pairs to a large cost, and solve it with linear_sum_assignment or the MATLAB assignmunkres function. Unassigned detections start tentative tracks. This shows you every decision the toolbox tracker makes. Keep the code modular so the association function can later be swapped for the greedy version.

   Checkpoint: The hand-written tracker keeps separate tracks on the side-by-side overtaking scenario at low clutter.

4. 4

   Add track management

   Implement M-of-N confirmation (for example 2 of 3) and deletion after K consecutive misses, plus a covariance-based deletion when uncertainty grows too large. Give each track a unique ID that persists for its life. Log track creation, confirmation and deletion events so you can count false tracks and breaks precisely. Try two or three settings of M, N and K on one scenario before the full study.

   Checkpoint: An event log showing tracks confirmed and deleted at the expected times in a simple crossing scenario.

5. 5

   Configure trackerGNN

   Set up trackerGNN with FilterInitializationFcn set to initcvekf, an AssignmentThreshold for the gate, ConfirmationThreshold and DeletionThreshold matching your M-of-N choices, and the Munkres assignment algorithm. Run it on the same detections as your own tracker. Compare the two trackers' outputs and explain any differences, which usually come from gate size or filter initialisation. Also note how the toolbox handles tentative tracks in its output, so that metrics count only confirmed tracks in both trackers. Record every parameter in a configuration file under version control.

   Checkpoint: trackerGNN and the hand-written tracker produce closely matching tracks on the baseline scenario.

6. 6

   Build the greedy baseline

   Implement greedy nearest-neighbour association: for each track in turn, take the closest gated detection not yet used. Keep the same filter and track management so only association differs. Run it on all scenarios. In dense scenes the greedy method tends to steal detections from neighbouring tracks, which is exactly the failure that motivates GNN. Process tracks in a fixed order, such as by track age, and record that order, because greedy results depend on it.

   Checkpoint: At least one scenario where the greedy method produces a track swap that GNN avoids.

7. 7

   Set up the metrics

   Use trackGOSPAMetric with a cut-off distance and order you justify, and trackAssignmentMetrics to count track swaps, breaks and false tracks against ground truth. Use trackErrorMetrics for position and velocity RMSE of correctly assigned tracks. Compute all metrics per time step and summarise them per scenario run. Check the metrics on a hand-made case with a known swap to make sure they report it.

   Checkpoint: A metric test showing a deliberately introduced track swap is counted correctly.

8. 8

   Run the Monte Carlo study

   For every scenario, clutter level and detection probability, run both trackers over at least 50 seeds. Record mean GOSPA, swaps, breaks, false tracks per minute and RMSE. Also measure processing time per scan as the number of objects and clutter points grows. Store results in a table so plots can be produced without rerunning simulations. Run everything from one script that writes a log of settings, so any single run can be reproduced later on demand.

   Checkpoint: A complete results table with every combination run and no missing cells.

9. 9

   Tune track management

   On a separate tuning scenario, sweep the gate threshold, confirmation M-of-N and deletion K, and plot false tracks per minute against time to confirm a real target. Choose a balanced setting and rerun the main study if it changes. Discuss the trade-off in terms of ADAS: late confirmation delays braking, false tracks cause phantom braking. Keep the tuning scenario out of the main results so the reported figures are not tuned to their own test data.

   Checkpoint: A trade-off plot of false tracks against confirmation delay with the chosen setting marked.

10. 10

    Analyse failures and report

    Pick the worst runs for GNN and replay them on the bird's-eye plot to explain each failure: closely spaced targets, missed detections during a manoeuvre or dense clutter. Write up the design, metrics, Monte Carlo results and failure analysis. Present results as means with confidence intervals. Release the scenarios and scripts so the comparison can be reproduced. Separate failures caused by the sensor, such as missed detections, from those caused by the tracker design.

    Checkpoint: A report with quantified comparison, failure case explanations and reproducible code.

Testing & validation

• Hand-written tracker matches trackerGNN on the baseline scenario.
• GOSPA, swaps, breaks and false tracks for GNN and greedy association.
• Results over clutter levels and detection probabilities with 50 seeds each.
• Processing time per scan against number of objects.
• Track management trade-off between false tracks and confirmation delay.

Expected results

A working GNN multi-object tracker with a quantified comparison against greedy association across clutter and detection levels, and a clear account of where GNN still fails.

Take it further

• Compare with JPDA and a track-oriented MHT tracker on the same scenarios.
• Add an IMM filter to each track for manoeuvring targets.
• Run the tracker on radar data from a public dataset such as nuScenes.
• Add camera detections and study multi-sensor association.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.