---
kind: concept
slug: continuous-time-state-estimation
title: Continuous-time state estimation
summary: >-
  Estimates a state that is defined at every time instant, not only at sensor timestamps, so it can be queried between samples. A sliding window of recent time steps keeps the cost bounded for live use. One paper so far: a 0.1 s window on a continuum robot matched or beat a 10 s batch smoother on all five trajectories, at 8.7 to 10.2 ms per step (author-reported).
tags: [state-estimation, continuum-robots, sliding-window, factor-graph]
papers: ["2510.26623"]
related: [pose-graph-optimization, error-state-kalman-filter, simultaneous-localization-and-mapping, cosserat-rod-theory]
status: draft
updated_at: 2026-11-01
---

## 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
[arxiv: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 [arxiv: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 [arxiv: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
[arxiv: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 [arxiv: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 [arxiv:2510.26623 §5]. Timings are
author-reported on one CPU [arxiv: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](/papers/2510.26623).

### 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 [arxiv: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
[arxiv:2510.26623 tab. 1]. The paper's stated concern is that linearising at each step can bias
the posterior for nonlinear systems [arxiv: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 [arxiv:2510.26623 §3.3.2]. The paper's main configuration uses a
0.1 s window [arxiv:2510.26623 §4]. It runs at 8.7 to 10.2 ms per step
[arxiv: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
[arxiv:2510.26623 §3.3.3]. The paper also describes reading from the front,
which is live, but reports no accuracy gain for it [arxiv: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 [arxiv:2510.26623 §4]. It takes about 1.36 s per step on the
paper's machine, so it is offline only [arxiv: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.

| Situation | Use | Why |
|---|---|---|
| Live, with a few ms per step and small accuracy loss acceptable | One-step filter | 4.0 to 4.4 ms per step. Its position RMSE was higher than the window on four of five trajectories, and tied on one [arxiv:2510.26623 tab. 1] [§4]. |
| Live at 30 Hz, accuracy close to the batch | Sliding window, 0.1 s | Under the 33.3 ms budget at 30 Hz. Matched the batch on three trajectories and was within 0.01 points on a fourth [arxiv:2510.26623 §4] [tab. 1]. |
| Offline analysis, no latency limit | Batch smoother | Best reference for accuracy. Too slow to run live [arxiv:2510.26623 tab. 1] [§4]. |
| Noisier or slower sensors (lower rate, larger noise) | Larger window | The authors expect larger windows to help with lower-rate, noisier sensors [arxiv:2510.26623 §5]. |
| Covariance needed between samples after the fact | Window greater than one step | The one-step filter does not allow continuous-time covariance queries. Larger windows do [arxiv:2510.26623 §3.3.4]. |
| Control loop that cannot tolerate lag | Filter or front-read estimate | The window's back-read estimate lags by up to the window length [arxiv:2510.26623 §3.3.3]. |
| Small per-step budget, no continuous covariance needed | Drop the continuous covariance | The paper reports a variant under 5 ms per step, over 200 Hz [arxiv:2510.26623 §5]. |

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 [arxiv: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 [arxiv:2510.26623 alg. 1].

```pseudocode
# 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
[arxiv: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](/papers/2510.26623): 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.