Seemorgh operator console
| Origin | Integration prototype built as a solo entry to the TYTAN counter-UAS multi-sensor fusion challenge |
| Open now | Recorded replay ↗ · Replay source and data ↗ |
| Checks | 91 of 91 timesteps without an anomaly · all 33 fusion tests pass |
| Pieces | FUSE engine · YOLO11n field sensor · local-model answers · Gemini canary (ran once) |
The console began with the TYTAN counter-UAS multi-sensor fusion challenge, where I built the original integration prototype as a solo entry. Five sensors watching the same airspace rarely agree. A long-range radar, a plot radar full of clutter, a precision tracker, an RF direction-finder that gives a good bearing but only a rough range, and a C2 network each report in their own frame, units, clock and idea of what an “id” is. Seemorgh’s FUSE engine turns those reports into one prioritised air picture. Each fused track keeps the list of reports it rests on and a modelled position uncertainty, so an operator can see what a track is made of, not just where it is.
It works on the scenario it was built for, including the hard part: a hostile drone and a friendly interceptor crossing paths between t=67 and t=81.
- 91 of 91 timesteps fuse without an anomaly in the timeline audit, and all 33 fusion tests pass.
- 3 of 1,092 reports from real objects were withheld across the whole run, and no report in any frame ended up in the wrong track.
- Stated uncertainty is about right: the hostile track’s true position falls inside it in 40% of frames, against 39% expected for an uncertainty of the right size.
- 14 of 15 recorded answers from the local model passed validation. The fifteenth fell back to a labelled deterministic answer.
In this project
Seemorgh operator console · Overview · 1 The crossing · 2 Sensors · 3 Fusion · 4 AI layer · 5 Checks · 6 Beyond the scenario
This page is the overview. The project is six more pages, meant to be read in order but each standing on its own:
- The crossing, frame by frame · 7 min
The story. Fifteen frames as two aircraft pass within 143 m, the one report the engine refused to place, and what refusing it cost. - Five sensors that disagree · 6 min
The inputs. Each feed’s frame, units, clock and ID; the uncertainty FUSE gives it; the scenario’s own simplifications. - How FUSE builds one picture · 6 min
The algorithm. Statistical gating, two-pass association, clutter, fusion, priority; t=74 worked through; textbook against judgement. - An AI layer with almost no room · 7 min
The model surfaces. Eight fences around a local model, fifteen recorded answers, and why they show a contract holding rather than judgement. - How it was checked · 7 min
The evidence. Ground truth hidden in report IDs, all 33 tests, the replay’s own checks, and whether the stated uncertainty is honest. - Beyond the scenario · 7 min
What came after. A two-camera sensor tested on a real drone (20–32 m off), a synthetic camera bridge that assumed 6 m, and a one-off Gemini canary.
The crossing also has a standalone note: When a report fits two tracks, leave it out.
The crossing at t=74
Recorded replay at t=74, with the map zoomed in on the crossing. Open the full console capture.
The same view in Sensor evidence mode: the reports as they arrived, before fusion. Open the full console capture.
At t=74 the two aircraft are about 145 m apart horizontally, and the engine receives 15 reports. Eleven of them become part of three tracks:
| Track | Classification | Priority | Source systems | Modelled σ | Confidence heuristic |
|---|---|---|---|---|---|
| FT-001 | Hostile | 1 | 4 | ±37 m | 0.755 |
| FT-002 | Unknown | 2 | 2 | ±72 m | 0.580 |
| FT-003 | Friendly interceptor | 3 | 4 | ±3 m | 0.939 |
Three of the four left out are stray plots, each at least 4 km from any track. The fourth is one of the drone’s own radar plots. By the engine’s own statistical distance, it fitted the friendly interceptor’s group slightly better than the drone’s, 0.32 against 0.40. A rule that took the best fit would have put the drone’s return into the friendly track. Because the second-best fit was within twice the best, the engine attached it to neither.
Read the full story: The crossing, frame by frame. It covers all fifteen crossing frames, that decision measured, and what leaving the plot out cost.
How it works
FUSE puts every report into metres about the ground station, with an uncertainty ellipse shaped by how that sensor errs. Reports are never matched by their IDs, because no two vendors share them. The engine groups them by geometry and identity calls, in two passes, and fuses each group into a track weighted toward its sharpest reports. It works one instant at a time, with no memory between frames.
Scrub the real picture
The replay at console.apps.mehridian.tech is the console’s own front end, reading 91 frames exported from the FUSE engine. Drag the timeline from t=0 to t=90, switch between the Air picture, Sensor evidence and Combined views, select a track and see which sources support it. Nothing runs live: there’s no server or model behind the page, and a note across the top says so. Every file is listed with its SHA-256, and the repository’s CI checks them on every push.
Limits
- Synthetic scenario. Tracks, sensor sites, classifications, uncertainty and RF bearings are scenario values, not field observations. Munich is a reference basemap and identifies no installation. See the scenario’s own simplifications.
- What the fusion is and isn’t. It’s single-instant fusion with greedy association, not a temporal tracker or a global assignment optimiser. The confidence figure is a heuristic, not a calibrated probability.
- Validated against one scenario. That’s the deterministic scenario it was given, not real multi-vendor data. See what isn’t checked.
- Recorded, not live. The model answers in the replay are one recording, and the model made no real choice in it.
- Not tried on physical devices. The replay was checked in desktop browsers and phone-sized viewports only.
- No operational use. The console explains evidence for human review. It never recommends or carries out an action.
Where it came from
The original brief was the TYTAN counter-UAS multi-sensor fusion challenge: take five incompatible vendor feeds and produce one prioritised, honest air picture that holds through a crossing. I built the original integration prototype as a solo entry. The challenge provided the scenario generator, and its output is published in the replay with permission. The fusion engine, the console, the field sensor and the bridge were built on top of it. Beyond the scenario covers what came after, with its numbers.
The application source stays private; the console’s front end and the replay data are public under Apache-2.0.
Connected work
- Builds on
- Small Objects in Big Frames — its detector and tiling, used in the field sensor · source
- Compared with
- Small Objects in Big Frames — a different kind of evidence, set side by side · source
Stated in the linked source unless marked as recollection. Connected work