How the live tracking demo works

The panel at the top of the home page is not an animation. It runs a Kalman filter in your browser, and the four numbers under it are measured while you watch. This note explains what the filter does, how each number is computed, and where the approach stops working.

The setup

A target moves across a panel 1000 units wide. A simulated sensor sees it 15 times a second, and every detection is off by Gaussian noise with a standard deviation of 11 units on each axis. That is the grey scatter around the path.

The filter runs on every animation frame, about 60 times a second. Between detections it predicts where the target has moved. When a detection arrives, it corrects that prediction. The white line is the filter's estimate; the dotted line is the true path, which the filter never sees.

The model

The filter assumes the target moves at a constant velocity, disturbed by random accelerations. Its state is position and velocity, and it keeps a covariance that says how sure it is about each.

state       x = [px, py, vx, vy]
predict     x ← F·x
            P ← F·P·Fᵀ + Q
update      K ← P·Hᵀ·(H·P·Hᵀ + R)⁻¹
            x ← x + K·(z − H·x)
            P ← (I − K·H)·P

F moves the position by velocity times the time step. H picks the position out of the state, because the sensor sees position only. R is the sensor noise, 11² on each axis. Q comes from a white-noise acceleration of 150 units per second squared: how much the filter expects the target to change speed or direction.

The orange path is the same predict step run forward 0.6 seconds without new detections. The ellipses are two standard deviations of the predicted position, taken from the covariance. They grow with the horizon because the filter is honestly less sure about the future.

What the numbers mean

Sensor error

The root-mean-square distance between each detection and the true position. With 11 units of noise per axis it settles near 11·√2, about 15.6.

Filter error

The same distance for the filter's estimate, measured at every detection. It is usually 7 to 9: the filter is roughly twice as accurate as any single detection, because it combines many of them with a model of motion.

Error 0.6 s ahead

At every detection the filter forecasts where the target will be 0.6 seconds later. When that moment comes, the forecast is scored against the true position. Typical values are 25 to 35 units, and they rise sharply when the target turns.

Filter step

The average time your device spends on one predict and update. On a laptop it is a few to a few dozen microseconds.

All errors are averaged over roughly the last six seconds. The first two seconds after loading are left out, while the filter is still finding the target.

Where it breaks

Constant velocity is wrong every time the target turns or brakes, so errors climb during maneuvers and recover once the motion is steady again. Steer the target sharply and you can watch the forecast swing and its ellipses widen.

The acceleration noise sets the trade-off. Raise it and the filter follows turns quickly but trusts each noisy detection more, so the estimate jitters. Lower it and the estimate is smooth but lags behind real changes. The value used here came from simulating many runs offline and measuring both errors, not from tuning by eye.

What the panel adds for display

Two things are there for readability and are not part of the filter. The drawn estimate eases each correction in over about 80 milliseconds, so the line does not jump 15 times a second; the numbers always use the raw filter state. And the target follows a goal point that moves at a limited speed, so that steering it feels like moving a real object rather than teleporting it.

Why this matters outside a browser

The same structure keeps track of objects between camera frames in video trackers, fuses satellite positioning with inertial sensors on drones and vehicles, and smooths sensor readings before forecasting. It costs microseconds, so it runs comfortably on a microcontroller next to the sensor.

When constant velocity is not enough, the next steps are richer motion models, several models run in parallel, or models of motion learned from data. That last direction is where our research on world models starts.

The demo is about 200 lines of plain JavaScript in main.js on this site, with no libraries.