Observer

Observer estimates every state of a plant, including the ones no sensor measures — a velocity from position alone, a load torque from motor current, a temperature inside a body from its surface. It runs a model of the plant, compares the model’s predicted measurement against the real one, and uses the difference to pull the model back toward the truth every cycle.

It is a plant model plus one correction term. Without that term the model drifts away from reality; with it, the estimate converges and stays converged.

flowchart LR
    i1(["inputVector — the plant's input"]) --> B["Observer"]
    i2(["measurementVector — what the sensors read"]) --> B
    B --> o1(["stateVector — the estimated states"])
    B --> o2(["stateDotVector — rate of change of the estimate"])
    B --> o3(["outputVector — the predicted measurement"])

The model is $\dot{\hat{x}} = A\hat{x} + Bu + L(y_m - \hat{y})$ and $\hat{y} = C\hat{x} + Du$. Tuning is entirely observerGain ($L$): it sets how fast the estimate is pulled toward the measurement. Place the observer 3 to 10 times faster than the plant. Faster converges sooner and passes more sensor noise into every estimate, and past a point it makes the block diverge — see Limits and errors. observerGain at zero leaves an open-loop simulation that ignores the measurement entirely.

Every matrix is written as one flat list, filled column by column. For a 4-state 2-measurement system the first four values of observerGain are the gains from the first measurement to all four states.

This block has no enable, no disable and no reset you can reach. It always runs, and its estimate cannot be re-initialised from the parameter tree — see Limits and errors.

Signals

Inputs

Outputs

Parameters

All six parameters are persistent and survive a controller restart. The inputs and outputs do not. No parameters exist below this block.

Setup

1. Write down your model’s dimensions: states, inputs, measurements. Read the lengths of stateVector, inputVector and measurementVector from the parameter tree and confirm they match. They are fixed when the machine is built.

2. Check that every state you want estimated is reachable through matrixC. A state that no measurement depends on, directly or through the dynamics, cannot be estimated at any gain.

3. Confirm your matrices are continuous-time. A discretised model will be wrong by a factor of the task period.

4. Write matrixA through matrixD as flat lists, column by column. For a 2×2 matrix the order is row 1 column 1, row 2 column 1, row 1 column 2, row 2 column 2.

5. Leave observerGain at zeros. Link inputVector from whatever commands the real plant, and measurementVector from the sensors.

6. Compare outputVector against measurementVector on one trace. With zero gain the model runs open loop, so the two will drift apart — but they should start out the same shape. If they are not, the model is wrong; fix that before adding any gain.

7. Raise observerGain from zero until outputVector tracks measurementVector closely.

   Step 7 is where this block becomes unstable if you push it. Too high a gain does not merely pass noise — it makes the estimate grow without bound, and only a controller restart clears it. Raise it in steps and watch stateVector between each.

8. Confirm stateVector settles and stays settled with the machine at rest.

Tuning

1. Get the model right first, with observerGain at zero, per Setup step 6. No gain can rescue a wrong model — it will give you a confidently wrong estimate with a small-looking error.
2. Work out your plant’s fastest pole, in rad/s. Aim to place the observer 3 to 10 times faster than that. That factor, not a number, is the target.
3. Raise observerGain from zero in steps of roughly double. After each step, watch stateVector for a few seconds with the machine at rest.
4. Stop as soon as noise appears on stateVector. Every measurement’s noise reaches every estimated state through the gain, and the states no sensor measures are usually the noisiest.
5. Judge convergence by subtracting outputVector from measurementVector. That difference is the observer’s error signal: it should be small in steady state and settle quickly after a disturbance.
6. Test convergence deliberately: start the controller with the machine away from zero, and time how long stateVector takes to reach the truth. That time is your observer’s response.
7. Check the gain against your task period. A gain fast enough to converge in a few task periods will make the block diverge — the practical ceiling is an observer response no faster than about a fifth of the task period.
8. If you need both fast convergence and quiet estimates, and your model is uncertain, use a Kalman filter instead — it trades the two off explicitly.

Read the convergence time off any curve as the point it crosses 0.37.

A starting point for estimating velocity from a position measurement on a 1 ms task. Two states — position and velocity — one input, one measurement:

matrixA      = 0, 0, 1, 0
matrixB      = 0, 1
matrixC      = 1, 0
matrixD      = 0
observerGain = 200, 10000

matrixA is column-major. Start with observerGain at zeros and work Setup steps 6 and 7. This is a starting point, not a final tuning.

Limits and errors

The block raises no errors or warnings and logs nothing. Every failure above shows as a value on a trace, not as a message.

Verified against motorcortex-control3 3.30.0 (bc348fd).