# What limits the observer eigenvalues size?

IIUC, the recommendation here of increasing the absolute size of the real part of observer eigenvalues is based on two factors:

• We want the observer to be updated as fast as possible (I suppose up to the point where it's so much faster than the controller that any further improvement of its update speed is pointless).
• There's no saturation problem since it's all in software.

What then prevents us from increasing observer eigenvalues without limit, i.e., driving them towards minus infinity?

Consider the state space controls equations:

$$u = -K\hat{x} \\ \dot{\hat{x}} = A\hat{x} + Bu + L\left(y - c\hat{x}\right) \\$$

The observer gain $$L$$ is essentially a measurement filter gain, where the observer is a "smart filter" in that it has the capability to predict (via $$\hat{x}$$) what the measurement should be.

If your observer gain $$L$$ is very large then your state estimate should converge faster, but you also can begin to feed all of your measurement noise through to your controller.

If your state estimate becomes too noisy and/or your state estimates change too quickly, then you begin to run the risk that your control signal $$u$$ will change so quickly that your plant/actuator can't keep up. This is called saturation.

This is a dangerous situation (from a controls perspective) because saturation causes your state estimate to diverge. Rewriting the controls equations:

$$\dot{\hat{x}} = A\hat{x} + Bu + L\left(y - c\hat{x}\right) \\$$

You can see that the control action $$u$$ will directly impact how your state estimates update. If your actuators aren't capable of keeping up with your control signal then you wind up "over reporting" the control action $$u$$ to your state estimator. This causes your state estimates to change more than they actually are, which can cause your observer to diverge because it is based on the difference between the measured output $$y$$ and the state estimate $$x$$.

The tl;dr here is that, even though observers are a software construct, they drive the plant on the basis that your control signal is driven by the observer output. Setting observer poles too "fast" results in actuator saturation because the plant/actuators can't keep up with the changes in the state estimates.

If you need more of an explanation then please let me know where you're unclear and I can try to add an edit. Hopefully this is enough.

• Thanks! So does this imply that it might be worthwhile, in some cases, to increase observer gain and at the same time reduce controller gain (to avoid over-saturating the actuators)?
– max
Oct 1 '18 at 15:58
• And another Q. Wouldn't the noise amplification from too much gain in the observer be a problem even if the controller does not run into saturation problem? For example, couldn't it cause the system to start oscillating unnecessarily?
– max
Oct 1 '18 at 16:04
• @max - Typically you choose the controller gains first to meet performance specifications. The thumbrule I was taught for observer gains is "5-10 times faster than the control poles." The system shouldn't oscillate unbounded in the presence of noise because unsaturated control signals should propagate through your system to the state estimate $\hat{x}$, which helps form the predicted output the observer expects. Oct 1 '18 at 18:03
• But you are correct in that you can excite your system, especially if your noise power happens to occur in a resonant band for your system. This is the tradeoff on the observer design (because all of engineering boils down to a tradeoff, right?) - faster observer poles get state estimates to converge faster, but if you set them too fast then your closed-loop system becomes very sensitive to noise. Oct 1 '18 at 18:06