Talk:Alpha beta filter

I am thinking over the details of a major rewrite for this page. Anybody objecting, having suggestions, willing to help...? ParaTechNoid (talk) 03:54, 9 November 2008 (UTC)

Article needs a better start

The very first line is not quite accurate:

"An alpha beta filter is a simplified form of Kalman filter which has static weighting constants instead of using co-variance matrices."

It not completely correct to compare the correction gains of the alpha beta filter to the noise model matrices of the Kalman filter. Kalman filtering uses formally computed, time-varying Kalman gains while alpha beta filtering uses the informally selected alpha beta gains, but both have gain terms, and this can be a point of confusion. A better wording might be to the effect: uses fixed correction gains instead of computing time-varying gains from a covariance model. But that is really only a secondary part of the story.

If you fix the Kalman gains and adjust them manually what you get is essentially a State observer, an intermediate form between Kalman filters and alpha beta filters. Explaining the alpha beta filters in terms of the state observers rather than Kalman filters makes some things easier. The more complicated relationship to Kalman filters could be discussed later.

The two really important difference are (1) that the Kalman and observer filters use a detailed dynamic model, while alpha beta filters assume a generic, simplified model for system dynamics; (2) the gain matrix for Kalman and observer filters in general maps multiple prediction errors (innovation terms, residuals) into corrections for multiple state estimates. The alpha beta filter uses a two-term gain matrix to map one prediction error into corrections for two simplified states. But of course, all of this is too much to say in one introductory line.

What to do about this? Well, I am working on it, really I am... but so far the revisions appear incompatible with the rest of the text.
ParaTechNoid (talk) 05:54, 10 November 2008 (UTC)

I've submitted a revised page that I believe addresses all of these points.
ParaTechNoid (talk) 00:43, 17 November 2008 (UTC)

New outline proposed

I'm boldly proposing the following outline for this article. This could seriously affect major linkages and that has me concerned... But the damage should not be extensive.

• Introductory lines
• Filtering method (covering concepts in the first part of the current "Implementation" section)
• Relationship to general state observers
• Relationship to Kalman filters
• The alpha beta gamma extension
• See also
• References
• Category

I rather like showing the application of the filter in a pseudo-coded algorithmic style, as currently done at the end of the implementation section, in addition to the update equation form. It helps to tie all of the pieces together. I just haven't found the obvious good place for it.
ParaTechNoid (talk) 06:33, 10 November 2008 (UTC)

I've submitted a revised page that I believe addresses all of these points.
ParaTechNoid (talk) 00:43, 17 November 2008 (UTC)

Technical glitches regarding variable definitions and constraints

These are some technical details to correct in the next revision of the page. Consider this a working checklist.

• x_m is the measured value, x_s is the smoothed value, x_p is the predicted value

Describing the variables is good, but it is important to clearly describe which variables refer to values prior to a state update, and which refer to values after a state update update.

x_s is the current estimate of state x,
v_s is the current estimate of state v,
x_p is the predicted value of state x at the next step, projected from the current value x_s
x_m is the measured value at the next step, corresponding to the time of the prediction x_p

• State based filters derive their outputs based on the filter state. This should be explicit.

x_s, v_s, or both can be used as filter outputs.

• 0 < α, β < 1

To avoid misinterpretation, a clearer display might be:

α, β >= 0
α, β > 0

• α=β=1: History has no effect

Untrue. History is the previous estimate. State estimates always start from the previous state estimates, plus incremental projection, plus incremental correction. Making larger corrections does not change this.
ParaTechNoid (talk) 07:50, 10 November 2008 (UTC)

One more final addition to the checklist. In the pseudocode description,

x=search true position around x

is extraneous. You can't search because you can't trust your measurements: they are noisy. The point of the alpha-beta algorithm is that it is a gradient process. The alpha and beta give a push (you hope!) in the right direction, and many such small pushes should average out to the corrections you want. No searching.
ParaTechNoid (talk) 08:09, 10 November 2008 (UTC)

I've submitted a revised page that I believe addresses all of these points.
ParaTechNoid (talk) 00:43, 17 November 2008 (UTC)

Take it easy

I just read this article (in its simple form) and it was exactly what I was looking for. Please be careful not to kill its simplicity and clarity with rigour and too much thoroughness. Also, I don't agree with your "no searching" comments; of course searching is optional and the effectiveness depends on noise, but the filter's prediction can help at least in some cases. (For example, in my application I'm using it to track an object in a video feed, and it suggests a good place to start the search from).--41.157.12.3 (talk) 19:53, 10 November 2008 (UTC)

Oops, I may have just killed its simplicity and clarity. But then again, maybe not. It might be simpler and clearer now. The rigor is mostly isolated in separate sections.

Re your comment about searching is optional: in the context of the original alpha beta filtering problem, search has no meaning. There is just one noisy signal, one crude internal state model. No options. To do better, you need an additional source of information (such as a supplementary analysis of a video stream). If you have this, it makes perfect sense to modify the algorithm to include the new information to further improve the state estimates -- but then it is not alpha beta filtering, but a new extended algorithm based on alpha beta filtering. There are many such cool extensions possible. Maybe that's what this page needs, a section about the range of possible extensions. It would be a nightmare for references, though.

ParaTechNoid (talk) 00:33, 17 November 2008 (UTC)

Slightly off-topic side observation: Tracking a trajectory through video frames is usually formulated as the dual problem to the one that alpha beta filtering addresses. To somewhat oversimplify, state estimators presume perfect model equations (e.g. classical mechanics), and if you get bad position and velocity predictions, the problem is poor input data (state). Parameter estimators presume good input data, and if you don't get good predictions, you are using poor parameter values in the model dynamic equations. If one estimates trajectory equation coefficients using an RLS updating rule with forgetting factor, that forgetting factor is closely related to the alpha and beta gains in alpha beta filtering. The trade-off in both problem formulations is between how much you trust your information estimated from past history, and how much you trust new data from noisy measurements. I suspect that a supplementary video analysis would integrate more naturally with the RLS framework.
ParaTechNoid (talk) 02:13, 17 November 2008 (UTC)

This sounds like the same thing as "double exponential smoothing"

This looks about the same as "double exponential smoothing" in the time series/forecasting field, in that it updates estimates of both position and velocity (derivative), and makes the prediction portion on the assumption that the velocity remains unchanged before the measurement-based correction of both position and velocity. See, for example, the section on double exponential smoothing in the Wikipedia article on Exponential smoothing. This is also discussed, with comparison to the Kalman filter, at [1] This link is broken, maybe you mean this paper? http://cs.brown.edu/people/jlaviola/pubs/kfvsexp_final_laviola.pdf — Preceding unsigned comment added by 111.223.77.82 (talk) 01:55, 2 January 2020 (UTC)

If it is basically the same thing, the article should say so. If it is different, the article should say why. Gmstanley (talk) 18:42, 26 September 2012 (UTC)

Intriguing observation! The time series / smoothing people were starting to develop their methods at about the same time that Kalman et. al. were working on their formalised model-based optimality proofs. While alpha-beta filtering can be said to have degenerated from formal theory, I don't think time series analysis ever had a similar theory. Your insight is likely correct, but even if these two approaches arrived at fundamentally the same place, the differing terminology, formulations, and notations obscure this. I don't think it is a good idea to research the relationships in this article. If you know of a paper or article where somebody has done that kind of study, it would make a great addition to the references. ParaTechNoid (talk) 01:17, 19 November 2012 (UTC)

Maybe the best way to address this is to have a short section on "related filters". This could include the comment that the general goal and approach is the same between alpha-beta filters and double exponential smoothing. We would cite the Wikipedia article on double exponential smoothing. Thus, this isn't original research, and is not making the claim that they are identical. They are simply related because they accomplish the same thing, and might be considered competitors. (We'd do the complementary comments under double exponential smoothing.) But a "related filters" section would be also good because we should have a place to compare to other competitive filters such as least squares filters, especially the Savitzky-Golay filter which is very simple to implement. A Savitzky-Golay filter can be thought of as a finite memory (FIR - finite impulse response) competitor for these IIR (infinite impulse response) filters. All of these filters have the goal of tracking a ramp input (and doing it exactly after a transient period), accomplishing it by simultaneously estimating and using the derivative. People reading about any one of these filters should be made aware of competitive approaches, and all of them already have articles written in Wikipedia. I could write up a short paragraph on this - is that agreeable? Gmstanley (talk) 18:47, 21 June 2013 (UTC)

Errata

I am not sure if this is an error or not because I did not do the math :-(

The article currently says for alpha-beta-gamma filter:

${\hat {\textbf {a}}}_{k}\leftarrow {\hat {\textbf {a}}}_{k}+(\gamma /[2\ \Delta {\textrm {T}}^{\textrm {2}}])\ {\textbf {r}}_{k}$

The book "Tracking & Kalman filtering made easy" by Eli Brooker p. 51 and http://www.comp.nus.edu.sg/~cs6240/lecture/tracking.pdf

say:

${\hat {\textbf {a}}}_{k}\leftarrow {\hat {\textbf {a}}}_{k}+([2\gamma ]/[\Delta {\textrm {T}}^{\textrm {2}}])\ {\textbf {r}}_{k}$ — Preceding unsigned comment added by 91.7.86.125 (talk) 21:55, 31 October 2012 (UTC)

Fix:: Hey unsigned, this is a good catch. I'm sure that my transcription error caused this inconsistency — appropriate that I should fix it. Strictly speaking there is no right and wrong since the alpha-beta-gamma algorithms works equally whether well normalised or not. However, IMHO, your referenced sources are better, first because there is value in being conventional unless there is a specific reason otherwise; and second, because the general kinematic expression for response to constant acceleration is ${\textbf {x}}_{k+1}\leftarrow \ {\textbf {x}}_{k}+{\textrm {a}}[{\frac {\Delta {\textrm {T}}^{\textrm {2}}}{2}}]$ where clearly the delta-T terms and the constant 2 are on opposite sides of the ratio. I have applied this change, consistent with the references. ParaTechNoid (talk) 23:58, 18 November 2012 (UTC)

First entry under Sources is a non-existent page

Should I edit myself? — Preceding unsigned comment added by Jamjamandcheese (talk • contribs) 16:27, 4 May 2020 (UTC)

Please do so! Biggerj1 (talk) 22:32, 1 July 2020 (UTC)