Bit of a theory question with a practical end. I’m estimating the state of a stormwater storage tank on a Pi at the site. Measurements: an ultrasonic level every 10 s, pump on/off status. I want inflow (unmeasured, from the catchment) and the outflow coefficient of a gravity outlet that partially silts up over months.
State x = [h, q_in, k], discrete EKF:
h[k+1] = h + dt/A * (q_in - k*sqrt(h) - pump*Q_p)
q_in[k+1] = q_in (random walk)
k[k+1] = k (random walk)
z = h + v
It tracks h fine, but q_in and k drift against each other and the filter happily trades one for the other. Sometimes k goes negative. I suspect observability. How do I check it properly for an EKF, and what can I change? The estimates go to Hermetry as telemetry for the ops board.
Way over my head but following, the tank-and-pump setup is the same as my rainwater barrel lol
Isn’t observability just the rank of the observability matrix? We did that in control class, but only for linear systems.
For an EKF you check it locally, on the Jacobians at the current operating point, but the intuition matters more: with one level sensor you see the net flow dh/dt, and q_in and k*sqrt(h) both enter it additively.
Did my master’s on state estimation before I drifted into IT, so this one I can answer.
Rahul is right that you check rank, just locally. Linearise at the current estimate: F = df/dx, H = [1 0 0]. Build O = [H; HF; HF^2] and check its rank (or better its condition number) along the trajectory. With your model, the q_in and k columns of HF are dt/A and -dt/A*sqrt(h). They’re independent only if sqrt(h) changes over the window. When the level sits still, O drops to rank 2 and the filter can trade q_in against k forever, which is exactly what you see.
What I’d change:
Give the two states different time scales. k changes over months, q_in over minutes. Make the process noise of k tiny (orders of magnitude below q_in) so the filter only moves k when there is evidence.
Use the excitation you have. When the pump runs, Q_p is known and the level moves, which is when k becomes identifiable. Some people only update k during pump cycles and dry-weather periods where q_in is near zero.
Keep k positive: estimate log(k), or clamp it.
If budget allows, one outlet flow measurement once a week (a portable meter) pins k and the problem goes away.
For the ops board, send the diagnostics too, not just the estimates:
{"h_m": 2.41, "q_in_ls": 38.2, "k_est": 0.0164, "innov_m": 0.004, "obs_cond": 1.2e3}
A chart of the innovation and the condition number tells you when to trust k. An alarm rule on obs_cond above some limit with a duration debounce is a cheap way to flag „k estimate unreliable right now“.
That explains it. Plotted obs_cond over a week: it shoots up exactly in the long flat-level periods. Gave k a process noise 1e-6 of q_in’s and switched to log(k). k now creeps slowly and only moves during pump cycles, q_in looks plausible against the rain gauge. Thanks Brian, and Rahul for the nudge.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Mitdiskutieren
Melde dich an, um Fragen zu stellen und zu beantworten, hilfreiche Beiträge mit „Gefällt mir“ zu markieren und die Antwort zu kennzeichnen, die dein Problem gelöst hat. Jeder Beitrag bringt Punkte und Stufen.