Prediction Filter

Node ID: prediction · Role: Filter · Realtime config: yes

Description

Latency compensation filter that extrapolates a FusedPose forward in time using angular velocity and optionally linear velocity. Used to reduce perceived tracking latency.

Algorithm notes

What this node computes

This node is a deterministic forward extrapolator, not a stochastic estimator: it carries no covariance, no gain, and no internal filter memory. Each incoming fused pose is propagated forward in time by a prediction interval and re-emitted, so the consumer sees an estimate of where the platform will be when the data is actually used rather than where it was when it was measured. Its purpose is latency compensation for render, display, or control loops.

The propagated quantities are orientation (a unit quaternion) and, optionally, position. Orientation is advanced by integrating rigid-body quaternion kinematics with a fourth-order Runge-Kutta step over the whole interval, assuming the angular rate is constant across that interval (angular acceleration is treated as zero). The incoming angular rate is interpreted in the reference frame of the pose and is rotated into the body frame before integration, so the result is consistent regardless of the platform’s current attitude. Position is advanced with a constant-acceleration model: current position plus velocity times the interval plus one half acceleration times the interval squared.

Two pose flavors are handled. A full 6-DOF pose is predicted directly in three dimensions. A vehicle pose is planar: heading is treated as rotation about the vertical axis, local position is extrapolated in two dimensions, and the geodetic position is converted to a metric grid (UTM, WGS84 ellipsoid), extrapolated there with the same velocity and acceleration, and converted back to latitude and longitude using the zone carried in the message. Vehicle poses are republished in both the current and legacy representations.

How input data is used

Only fused pose messages are consumed; anything else on the input is ignored. Angular velocity is expected in degrees per second and is converted internally; velocity and acceleration are expected in the same length units as position, per second and per second squared. There is no initialization phase and no convergence transient: the node is effectively stateless between samples, so the very first pose produces a fully valid predicted output, and prediction error never accumulates because every frame restarts from a freshly fused input. The last predicted pose is retained only for query purposes.

Outputs are tagged with a marker describing the applied interval (either the configured value in milliseconds or an indication that the measured age was used), which is useful when tracing latency through a chain of nodes.

Parameters by concern

How much to predict. The rotation and position intervals set the look-ahead horizon in seconds. Zero disables the corresponding prediction, which turns the node into a pass-through for that quantity.

What to predict. Position extrapolation is opt-in. With it off, position and velocity pass through untouched and only attitude is advanced.

Where the interval comes from. In fixed mode the configured intervals are applied on every frame. In measured mode the interval is derived from the age of each incoming pose, so the compensation tracks actual pipeline jitter; in that mode a single measured value drives both orientation and position, and the configured position interval is not used.

The rotation interval can be changed at runtime through the node’s configuration command; the remaining settings are applied at construction.

Tuning and failure modes

Start by measuring the real end-to-end delay between fusion output and consumption, then set the rotation interval slightly below it. Prediction amplifies rate noise linearly with the interval, so over-predicting yields visible jitter and overshoot at motion reversals; under-predicting is usually the safer error. Position prediction scales with the square of the interval when acceleration is nonzero, so keep the position interval short and only enable it when velocity and acceleration are well filtered.

Known pitfalls: with vehicle poses in fixed-interval mode no prediction is applied at all, only tagging, so use measured mode for vehicle pipelines. Measured mode depends on clean, clock-synchronized timestamps; stale or skewed clocks produce absurd or negative intervals and can throw the pose backwards. Angular rates supplied in radians rather than degrees will under-rotate by a large factor. Long intervals combined with rapidly changing rates violate the constant-rate assumption. Geodetic prediction degrades near UTM zone edges and at extreme latitudes, and requires a valid zone in the incoming message.

Inputs / Outputs

• Inputs: FusedPose
• Outputs: FusedPose

Config aliases

PredictionFilter, predictionFilter, prediction

Properties

The following fields are exposed in the node’s Properties panel in the UI. Types map to UI widgets (e.g. string → text input, number → numeric, boolean → toggle, select → dropdown, json → JSON editor).

Example node definition

A full node definition in config.json looks like the block below. Paste it under the sinks key of your config, keyed by the node’s instance name (any identifier; it doesn’t have to match the node ID).

{
  "sinks": {
    "prediction": {
      "dataEndpoint": "inproc://prediction_data",
      "inputEndpoints": [
        "inproc://fusedPose_data"
      ],
      "inputDataFilter": [
        "FusedPose"
      ],
      "settings": {
        "fixedPredictionInterval": true,
        "positionInterval": 0.0,
        "predictPosition": false,
        "rotationInterval": 0.0
      }
    }
  }
}

Field reference

Connections can also be declared at the top-level connections array when settings.explicitConnections is true, as an alternative to filling inputEndpoints on each node.