File Exchange Pick of the Week

Learning the (Linear) Kalman Filter 6

Posted by Brett Shoelson,

Brett's Pick this week is "Learning the Kalman Filter", by Michael Kleder.

If one were to sort the entries of the File Exchange by the number of downloads in the past 30 days, an interesting trend would become apparent: a handful of files have been downloaded far more times than the vast majority of the rest of the files on the Exchange. Of those, one file in particular has been dowloaded 43% more times than the next most popular file.

The popularity of Michael's "Learning the Kalman Filter" mini tutorial (as of this writing, it has been downloaded 2803 times in the past 30 days--even though the file has been up for 6 years!), along with the great feedback it has garnered (73 comments and 67 ratings, averaging 4.5 out of 5 stars), initially caught my eye.

Michael wrote in the preamble to his tutorial:

%%%%%%%%%%%%%%%%%%%

Many people have heard of Kalman filtering, but regard the topic as mysterious. While it's true that deriving the Kalman filter and proving mathematically that it is "optimal" under a variety of circumstances can be rather intense, applying the filter to a basic linear system is actually very easy. This Matlab file is intended to demonstrate that.

%%%%%%%%%%%%%%%%%%%

In his in-file example, Michael then steps through a Kalman filter example in which a voltmeter is used to measure the output of a 12-volt automobile battery. The model simulates both randomness in the output of the battery, and error in the voltmeter readings. Then, even without defining an initial state for the true battery voltage, Michael demonstrates that with only 5 lines of code, the Kalman filter can be implemented to predict the true output based on (not-necessarily-accurate) uniformly spaced, measurements:

This is a simple but powerful example that shows the utility and potential of Kalman filters. It's sure to help those who are trepid about delving into the world of Kalman filtering.

A couple notes on Michael's implementation... First, note that the return statement at the end of his function is extraneous. But perhaps this code was culled from a larger file in which that command served some purpose? Also, as one commenter noted, and as the MLINT Code Analyzer points out, inv(A)*B is better written as A\B. There's a similar suggested substitution for A*Inv(B), both of which can be rendered faster and more accurate using the backslash (matrix left division) operator.

Comments?.


Get the MATLAB code

Published with MATLAB® 7.11

6 CommentsOldest to Newest

Placing a return at the end of the function is a standard way to allow placing a breakpoint just before the function returns, in order to debug the computations, see all the internal variables’ values etc. Since the return call is not translated into any extraneous run-time code, this is a very easy and non-intrusive way to do this.

@Yair: maybe I didn’t understand correctly, but couldn’t the same result be produced by ending the function with an “end” command and placing a breakpoint on that?

The January 25th, 2008 comment by Yi Cao is an important one.

If you execute the “kalmanf.m” script-file using the parameters Michael (Kleder) defines in the commented-out lines of his script-file, without changing anything, the Kalman gain is slightly greater 0.6. However, if you make the changes noted by Yi, the gain is 0.5.

A gain of 0.5 is expected in this case because the process and measurement definitions are the same. That is to say, the process model (i.e. the state-transition matrix – a scalar in this example) and the measurement model are the same – unity, and the respective noise standard deviation is the same – 2 volts.

Michael.

@Yair (and Luca):
Point taken. I often do things like that, but then remove the “place-holder command” before I commit or submit my code. The “return” (or “end”) doesn’t hurt anything.

@Michael:
I’m a neophyte when it comes to Kalman filters; I’ll leave those ponderings to those of you who are more versed on the topic.

These postings are the author's and don't necessarily represent the opinions of MathWorks.