Continuous-time state estimation

Overview

The problem is to estimate a state that changes over time when sensors report at irregular times and the estimate must be available live. The state in 2510.26623 §3.1 is defined for every time t and every arc length s along a continuum robot. The estimate can therefore be read at any time, not only at a sensor timestamp. The sensors in that paper are asynchronous 2510.26623 §3.4.2.

The invariant that the variants share is the model and the measurements. The state is a pose, a velocity and a strain, and each measurement adds a factor to a maximum a posteriori problem 2510.26623 §3.1. The variants differ only in how much past data stays in that problem. The paper frames the one-step filter, a sliding window and a full batch as points on one scale of window length 2510.26623 §3.3.4.

The paper's motivation is the gap between two existing options. Filters run live but linearise at each step, which can bias nonlinear problems. Batch smoothers are more accurate but cannot run online 2510.26623 §1.

All evidence so far comes from one paper: one tendon-driven robot, one sensor set, and five 10 s trajectories. The authors state that only one robot and one sensor configuration were tested 2510.26623 §5. Timings are author-reported on one CPU 2510.26623 §3.4.1.

Variants

All three variants below appear in one paper's experiments. They differ by window length. Card for all three: the paper's card.

One-step filter (window of 0 s)

The state is re-estimated from each new measurement using one time node. The paper calls this the 0 s window 2510.26623 §3.3.4 §4. It is the cheapest option, at 4.0 to 4.4 ms per step on the paper's hardware 2510.26623 tab. 1. The paper's stated concern is that linearising at each step can bias the posterior for nonlinear systems 2510.26623 §1.

Sliding window (the paper's 0.1 s SWF)

A window of recent time steps is re-solved each time a measurement arrives. The oldest state is folded into a prior with a Schur complement, so the problem size stays fixed 2510.26623 §3.3.2. The paper's main configuration uses a 0.1 s window 2510.26623 §4. It runs at 8.7 to 10.2 ms per step 2510.26623 tab. 1.

The reported state is read from the back of the window. That state includes all measurements in the window but lags by up to the window length 2510.26623 §3.3.3. The paper also describes reading from the front, which is live, but reports no accuracy gain for it 2510.26623 §5.

Batch continuous-time smoother (window of 10 s)

The whole recording is solved at once. It is the accuracy reference in the paper's table 2510.26623 §4. It takes about 1.36 s per step on the paper's machine, so it is offline only 2510.26623 tab. 1.

When to use which

The choice depends on the per-step time budget, whether the estimate must run live, and how much accuracy the application needs. The numbers are the paper's, for one robot and one sensor set.

Larger windows do not always help. On the Out-of-Bounds trajectory, position error rose at larger windows, and the authors suspect the pose sensor's boundary measurements, which the batch then overfits. This is a hypothesis the paper did not test 2510.26623 §4 §5.

Implementation sketch

The loop below is the common core of the sliding-window variant. Where the one-step filter differs, set the window length to one time step. Where the batch differs, never marginalise. The paper's own algorithm is 2510.26623 alg. 1.

# Sliding-window estimator, common core  [arxiv:2510.26623 §3.2] [§3.3]
# Input:  prior on the first state, window length w (seconds), measurements
# Output: one state estimate per new measurement

def sliding_window(prior, w, measurements):
    # Start with the prior as the only factor and an empty window  [§3.2]
    factors = [prior]
    nodes = []
    for m in measurements:
        # Add time nodes until the window covers the new measurement time [§3.3.1]
        nodes = extend_nodes(nodes, m.time)
        # Add motion, spatial, boundary and measurement factors  [§3.2]
        factors = add_factors(factors, nodes, m)
        # Re-solve the MAP problem over the window  [§3.1]
        nodes = gauss_newton(factors, nodes)
        # Read the state from the back of the window, which lags  [§3.3.3]
        yield nodes.back
        # Fold the oldest state into a prior when the window is too long [§3.3.2]
        if nodes.span > w:
            factors = marginalise_oldest(factors, nodes)
            nodes = drop_oldest(nodes)

The loop does not stop Gauss-Newton on its own. The paper gives no stopping rule, and the shipped code uses a step-size threshold with an iteration cap 2510.26623 §3.1. Choose and test both on your own data.

Contradictions

None known. This page cites one paper so far.

Papers

• Sliding-window filter for continuum robots: a sliding-window factor-graph estimator for a continuum robot's pose, velocity and strain, compared with a one-step filter and a 10 s batch smoother on five trajectories.