Detect. Resolve. Predict. Task.

Click a resolved entity on the link chart → the predictor extrapolates its position 10 minutes forward using great-circle constant-velocity math (with least-squares smoothing over recent track history) → the predicted track renders as a dotted amber line on the map → you confirm a DJI drone orbit at the predicted position → the mission pushes to the RC. The full Palantir "detect → resolve → predict → task → collect" loop, running air-gapped on your hardware.

Constant-velocityLeast-squares fitGreat-circle FlyPath orbitDJI WPML pushEntity-aware100% local

The prediction engine

Where will it be in 10 minutes?

The TrackPredictor projects a resolved ontology entity forward in time using constant-velocity great-circle extrapolation — the same proven math the fusion deconfliction loop already uses for closest-point-of-approach. No Kalman filter, no cloud round-trip: the prediction runs on the entity's latest speed + heading, smoothed by a least-squares fit over recent track history when available.

Two-tier kinematic resolution — Properties JSON blob first (the entity's latest speed/heading from the resolver), then a fallback to TemporalAnalyticsService.History via aliases (with cot→tak, adsb→sdr source-name translation).
Least-squares smoothing — when ≥3 recent track positions are available, the predictor fits a linear velocity vector (east/north components regressed against time) to smooth noisy single-sample course/speed readings. Falls back to the last sample when history is thin.
Great-circle Destination math — projects forward speed × lead-time meters along the fitted heading, sampling 6 intermediate points for a smooth dotted-line render.
Graceful degrade — no position, no kinematics, or stationary? The predictor returns an honest error, never throws.

POST /api/prediction/predict

# request
{ "entityId": "ENT-ae4b1f", "leadMinutes": 10 }

# response — predicted position + track polyline
{
  "predictedLat": 34.0522,
  "predictedLon": -117.3510,
  "headingDeg": 90.0,
  "speedMps": 100.0,
  "distanceM": 60000,
  "source": "history-ls",
  "path": [[-118,34], [-117.87,34], ...]
}

● constant-velocity · least-squares smoothed

The tasking loop

From predicted position to flying mission

The predicted coordinate hands off to FlyPath — the mission planner — which builds a DJI WPML orbit mission, then pushes it to the RC's waypoint folder. One click from the entity card to a flying drone.

🎯

Predict

Click 🎯 on the entity detail card in the link panel. The predictor extrapolates the track + renders a dotted amber predicted-position line on the map.

🛩️

Plan orbit

Confirm "Task DJI drone to orbit?" → FlyPath builds an orbit mission (200 m radius, 100 m AGL) centered on the predicted position. The mission's waypoints + footprints render on the map.

📡

Push to RC

Confirm "Push to RC?" → the WPML kmz copies into the DJI RC's waypoint folder via Windows IFileOperation. The operator launches the mission on the RC — the drone flies to the predicted position.

The full loop

Detect → Resolve → Predict → Task → Collect → Re-resolve

This isn't a standalone feature — it's the capstone that closes the loop on everything the platform already does. The ontology resolves the entity across feeds. The predictor extrapolates. FlyPath tasks the drone. The drone collects imagery. The collection re-feeds the ontology on the next ingest cycle — and the picture gets sharper.

Entity-aware — the prediction keys on a canonical entity id, not a raw feed-native track id. So it follows the entity across feed renames and alias additions.
FlyPath integration — the orbit mission uses the same FlyPathPlanner + WPML writer that powers the UAS mission-planning surface. No new planner code — composition.
RC push wired — RcPushService.PushAsync was written but had no route. Now POST /api/flypath/push wraps it — the plan actually flies.
Honest about limitations — constant-velocity is not a Kalman filter. It's an extrapolation, not a probability distribution. The dotted line is a forecast, not a guarantee — and the UI says so.

the loop · air-gapped

# the full cycle, no cloud round-trip
1. Detect     feeds (TAK/ADS-B/ASTERIX/AIS)
2. Resolve    ontology fuses feeds → 1 entity
3. Predict    TrackPredictor → Destination math
4. Task       FlyPath orbit @ predicted position
5. Collect    drone imagery → COG/Photo registry
6. Re-resolve next ingest sharpens the picture

● detect → resolve → predict → task → collect
  all local · no cloud AI · no server backend

The prediction is a constant-velocity great-circle extrapolation — a forecast, not a tracking filter. It assumes the entity continues at its current speed and heading, which is accurate for short lead times (minutes) and degrades for longer horizons or maneuvering targets. A Kalman/alpha-beta filter with covariance modeling is a documented follow-up once observational noise data exists in the track schema. The FlyPath RC push requires a DJI RC connected via USB; the kmz copies into the waypoint shell folder via Windows IFileOperation. Skydio command/tasking is deferred (no command endpoint exists today).